[GHC] #13523: Be more explicit in generated case alternatives

GHC ghc-devs at haskell.org
Tue Apr 11 13:26:01 UTC 2017


#13523: Be more explicit in generated case alternatives
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:  (none)
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by rwbarton):

 * status:  closed => new
 * resolution:  invalid =>


Comment:

 This was not about algebraic cases but primitive cases, for example on
 `Int#`. As far as I know the only situation where this will arise is when
 transforming
 {{{#!hs
 case tagToEnum# (x ==# y) of {
   False -> ...
   True  -> ...
 }
 }}}
 to
 {{{#!hs
 case x ==# y of {
   0# -> ...
   1# -> ...
 }
 }}}
 By using `0#` and `1#` rather than `1#` (or `0#`) and `__DEFAULT` we could
 convey to the backend the information that the scrutinee is guaranteed to
 evaluate to either 0 or 1. With just two cases this probably doesn't
 matter, but when there are many cases we'd like to generate a jump table
 and if we know the scrutinee is guaranteed to be in-range then we can skip
 range checks.

 For an example usage, see `toChunk3#` in the attachment to #9159.

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


More information about the ghc-tickets mailing list