Re: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect

4 Oct 2018

      #15696: Derived Ord instance for enumerations with more than 8 elements seems to be
incorrect
-------------------------------------+-------------------------------------
        Reporter:  mrkkrp            |                Owner:  (none)
            Type:  bug               |               Status:  patch
        Priority:  highest           |            Milestone:  8.6.2
       Component:  Compiler          |              Version:  8.6.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Incorrect result  |  Unknown/Multiple
  at runtime                         |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D5196,
       Wiki Page:                    |  Phab:D5201
-------------------------------------+-------------------------------------

Comment (by simonpj):

 Comments about Phab:D5201. I'm not looking at the details yet (it's just a
 draft), but

 * I think this is the Right Place to deal with `dataToTag#`.  Bravo.

 * The known-constructor case surely will be handled in the simplifier; if
 not now then soon.  Handling it here is not wrong, but probably
 unnecesssary.

 * The thing that we CAN ONLY handle here is
 {{{
 ...(case x of y {
         A -> blah
         DEFAULT -> ....(dataToTag# y)...
 }}}
   Here we know that `y` really points to the value, so `dastaToTag#` does
 not need to do a redundant eval.

 However I have just realised that this optimisation is available for
 '''any''' case expression, not just `dataToTag#`.  Consider

 {{{
 ...(case x of y {
         A -> blah
         DEFAULT -> ....(case y of
                           B -> blah2
                           C -> blah3
                        )...
 }}}
 Here we know that `y` is fully evaluated and points to the final value;
 that's the promise of the outer case expression.  So we can directly test
 y's tag bits without worrying that it might be unevaluated, need to build
 a return point and info table etc.  Ha!

 I'm not sure how common this is.  But perhaps it is worth a separate
 ticket.

-- 
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:46
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler