Skip to content

Commit 0514542

Browse files
committed
Update README.md
1 parent c56f2c6 commit 0514542

File tree

1 file changed

+11
-3
lines changed

1 file changed

+11
-3
lines changed

README.md

Lines changed: 11 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -33,7 +33,7 @@ test1 :: Double -> Double
3333
test1 d = d*10 + d*20
3434
```
3535

36-
GHC factors out `d`, then folds the constants, producing the core:
36+
With the `fast-math` library, GHC factors out `d`, then folds the constants, producing the core:
3737

3838
```
3939
test1 :: Double -> Double
@@ -44,7 +44,7 @@ test1 = \ (d :: Double) ->
4444
But if we make the code just a little more complicated:
4545

4646
```
47-
test2 = d1*d2 + (d3 + 5)*d1 + d1*32
47+
test2 d1 d2 = d1*10 + d1*d2 + d1*20
4848
```
4949

5050
Then GHC distributes successfuly, but can't figure out how to fold the constants. It produces the core:
@@ -59,7 +59,15 @@ test2 = \ (d1 :: Double) (d2 :: Double) ->
5959
}
6060
```
6161

62-
We could fix this problem if the `RULES` pragmas could identify constants instead of variables. This would let us commute/associate the constants to the left of all computations, then GHC's standard constant folding mechanism would work successfully.
62+
If we change the code so that the constants appear next to each other:
63+
64+
```
65+
test3 d1 d2 = d1*d2 + d1*10 + d1*20
66+
```
67+
68+
then GHC successfully combines the constants.
69+
70+
We could fix this problem if the `RULES` pragmas could identify which terms are constants and which are variables. This would let us commute/associate the constants to the left of all computations, then GHC's standard constant folding mechanism would work successfully.
6371

6472
**The best way to check what optimizations are actually supported is to look at the source code.** `RULES` pragmas are surprisingly readable.
6573

0 commit comments

Comments
 (0)