Allowing rules to depend upon SimplCont

Ben Gamari ben at smart-cactus.org
Mon Mar 2 14:13:23 UTC 2015


Simon Peyton Jones <simonpj at microsoft.com> writes:

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150302/4300e84b/attachment.sig>


More information about the ghc-devs mailing list