#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