Simon Peyton Jones
Ben
Is there a wiki page that describes this project? - goals, and motivation - design of the change - any implementation notes
Not that I'm aware of. I can perhaps fix this.
I've lost context and #9661 is too long to suck up. A wiki page can carefully explain the story, without all the to-and-fro.
#9661 arose out of the unboxed boolean work implemented by Jan (#6135) which should allow us to produce much better code for some types of case analyses by avoiding branches. Unfortunately, it appears that the `litEq` rule is rewriting the `==#` into a case expression. Take the example, f :: Int -> IO () f (I# n) = case isLucky n of True -> print "Bingo!" False -> return () isLucky :: Int# -> Bool isLucky n = n ==# 33 `orI#` n ==# 42 `orI#` n ==# 57 Note that `isLucky` takes care to express its test as unboxed boolean operations. This is supposed to be our way of telling the compiler that we'd really like it to emit something like the following pseudo-machine code, R1 = load $n R2 = eq R1, 33 R3 = eq R1, 42 R5 = eq R1, 57 R4 = or R2, R3 R4 = or R4, R5 jumpnz R4, print_bingo return Unfortunately the `litEq` rule is rewriting the `==#` applications into case expressions which the simplifier then merges, f (I# n) = case n of 33 -> print "Bingo!" 42 -> print "Bingo!" 57 -> print "Bingo!" _ -> return () Which then gets turned in to a sea of branches (see for instance the example in #10124). The goal of this project is to allow `litEq` to sense the context of the term it is considering so that it will avoid interfering with terms like `isLucky n` in case analyses.
| 1. Pass a dummy `SimplCont` (probably a `Stop`) to the `RuleFun`. | This | is by far the easiest option but will result in discrepancies | between the rule check and the rules actually fired by simplifier.
I'm honestly not sure if anyone actually uses ruleCheck. I'd punt on it for now, and use (1). Document the imperfection in the user manual, cross-referencing the wiki page.
Alright, this sounds reasonable.
| I've split up `SimplUtils.hs` into `SimplCont.hs` and | `SimplInline.hs`. Given these two have no cross-dependencies this | seems like a reasonable split even independent of the `RuleFun` | rework.
I'm not sure that all the residue of SimplUtils concerns inlining, does it? Maybe leave the residue as SimplUtils.
I would strive hard to avoid another hs-boot file if poss.
Alright, I will revisit this once the meat of the project is in a better state. Thanks, - Ben