[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