[GHC] #10676: silly assembly for comparing the result of comparisons that return Int# against 0#

[GHC]

#10676: silly assembly for comparing the result of comparisons that return Int#
against 0#
-------------------------------------+-------------------------------------
        Reporter:  rwbarton          |                   Owner:
            Type:  bug               |                  Status:  closed
        Priority:  normal            |               Milestone:
       Component:  Compiler          |                 Version:  7.10.1
  (CodeGen)                          |
      Resolution:  duplicate         |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:  x86_64
 Type of failure:  Runtime           |  (amd64)
  performance bug                    |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:  #8326, #8327,     |  Differential Revisions:
  #9661                              |
-------------------------------------+-------------------------------------

Comment (by rwbarton):

 Replying to [comment:7 simonpj]:
 > Wait!
 >
 > I believe that you are saying that [...]

 Yes that's right. Tickets #8326 and #8327 cover everything I had to say
 about the code generated here.

 > Where would be a good place to document it? Perhaps with the primops for
 `(==)#`, `(>=)#`, etc? Or with `isTrue#`?

 Ideally with the comparison primops, but they are numerous and scattered
 throughout the list of primops, which is organized principally by type
 (`Char#`, then the integral types, etc.). There is some mention of this
 phenomenon in the Note `[Optimizing isTrue#]`, though you have to read
 between the lines a bit.

 It would be best to fix this of course, but if that stalls then I'll add a
 comment near the top of `primops.txt.pp`.

 > Speaking of which do you know why it behaves so badly?

 There is a special case for `cgCase` on an enumeration type of a primop
 application: in this case we always raise heap checks out of the
 alternatives. I think this is the entire reason for the difference between
 the code generated for the two versions. I don't see why it makes sense to
 have different logic for how to place the heap checks in this case
 compared to the general case, and I'm not entirely sure it isn't a
 historical accident.

 Further comments on #8326.

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