[GHC] #9661: Branchless ==# is compiled to branchy code

[GHC]

#9661: Branchless ==# is compiled to branchy code
-------------------------------------+-------------------------------------
              Reporter:  dfeuer      |            Owner:
                  Type:  feature     |           Status:  new
  request                            |        Milestone:
              Priority:  normal      |          Version:  7.9
             Component:  Compiler    |         Keywords:
            Resolution:              |     Architecture:  Unknown/Multiple
      Operating System:              |       Difficulty:  Unknown
  Unknown/Multiple                   |       Blocked By:
       Type of failure:  Runtime     |  Related Tickets:
  performance bug                    |
             Test Case:              |
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------

Comment (by dfeuer):

 Replying to [comment:12 simonpj]:

 > So a chain of equality comparisons will turn into a table-driven jump in
 the end, which is a good thing.  On the other hand, generating branch
 nests is a bad thing.

 You call this a "table-driven jump", and that may be the case for
 something like `0,1,2` (I don't know), but it certainly does ''not'' seem
 to work like that for, say, `32, 9, 10, 11, 12, 168`, or whatever the
 numbers are for "is a space".

 > So perhaps `litEq` should apply only ''when in the context of a `case`
 expression that immediately scrutinises its result''.  So `litEq` would
 become
 > {{{
 >    case (a ==# k) of 1# -> e1; _ -> e2
 > --->
 >    case a of { k -> e1; _ -> e2 }
 > }}}
 > Annoyingly, the `CoreSyn.RuleFun` API for built-in rules does not give
 access to the context of an application (the `SimplCont`), but it would
 not be hard to make it do so.
 >
 > So if that is the right rewrite, then it'd be another useful project for
 someone.

 I don't have a clear sense of what you're getting at, but in the
 situations I'm thinking about (avoiding poorly predicted branches), the
 compiler may not be able to know what is best, and Reid Barton's "secret"
 equality predicate may be the best approach.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9661#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler