[GHC] #10137: Rewrite switch code generation

[GHC]

#10137: Rewrite switch code generation
-------------------------------------+-------------------------------------
        Reporter:  nomeata           |                   Owner:
            Type:  task              |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Compiler          |                 Version:  7.9
  (CodeGen)                          |                Keywords:
      Resolution:                    |            Architecture:
Operating System:  Unknown/Multiple  |  Unknown/Multiple
 Type of failure:  None/Unknown      |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:  #9157, #8326,     |  Differential Revisions:
  #8317, #9159                       |
-------------------------------------+-------------------------------------
Changes (by rwbarton):

 * related:  #9157, #8326, #8317 => #9157, #8326, #8317, #9159


Comment:

 Also see the comments of #9159.

 > The case of enumeration types will be reduced to word literals, and
 treated the same from now on.

 Note that when matching on an enumeration type, we can assume that the
 constructor tag is within the range of possible tag values. We cannot make
 any such assumption for matches on ints. So, we should remember the extra
 information that we have about the range when doing this reduction. I
 imagine you will have a function to generate code for an int pattern match
 with known bounds anyways, as part of a binary search algorithm, so this
 should not complicate the code greatly.

 > Matching against literals literals is fishy anyways, so my suggestion is
 to simply generate a linear list of equality checks here – turning the
 intended operation (equality test) into something else (comparisons in a
 if-then-else tree) feels wrong to me for floats.

 I don't see anything wrong with using comparisons for pattern matching on
 floats as long as the patterns are all finite numbers (though there is
 trickiness around negative zero to be aware of). But I also think float
 pattern matching is much less important than your other goals, so I would
 agree with doing something simple for floats, at least initially.

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