[GHC] #14880: GHC panic: updateRole

[GHC]

#14880: GHC panic: updateRole
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  goldfire
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.8.1
       Component:  Compiler (Type    |              Version:  8.2.2
  checker)                           |
      Resolution:                    |             Keywords:  TypeInType
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  crash or panic                     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #15076            |  Differential Rev(s):  Phab:D4769
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by tdammers):

 Replying to [comment:106 goldfire]:
 > I might have time to take a look at this, but I'll need a bit more
 direction. You say that you might have missed something -- what two
 branches can I compare to assess that?

 I think you may be missing some context here, so here's the executive
 summary:

 - Your original patch is on `wip/T14880`
 - The baseline HEAD from right before your patch is on
 `wip/T14880-baseline`
 - Simon's patch (as mentioned above) is on `wip/T1448-accum`
 - `wip/T14880-reengineered` contains your patch (as on `wip/T14880`), with
 the approach from Simon's patch applied practically verbatim.

 Now here's the conundrum:

 - The baseline version performs within limits
 - Your patch applied as-is fails two performance tests: 5321Fun and 5631
 - Simon's patch improves performance on 5631
 - But Simon's approach applied to your patch doesn't

 > As for the one-line change: it's seems conceivable that the change could
 have a measurable performance impact. Have you tested the change,
 independent of anything else? If the fix makes performance worse, that
 would be an insight, because the `acc` check looks like it's only an
 optimization, not an essential check for correctness.

 It is only an optimization, but that's the whole point of digging further
 here - the patch allocates more even though we would it expect it to
 allocate less. AFAIK there are no correctness issues anymore. The patch
 without the `acc` check fails the two performance tests, but so does the
 version with the check.

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