panic when compiling SHA

[Ben Lippmeier]

On 06/01/2014, at 19:43 , Simon Peyton-Jones <simonpj at microsoft.com> wrote:

> | Note that removing the flag isn't a "solution" to the underlying problem
> | of the intermediate code being awful. Switching to the linear allocator
> | just permits compilation of core code that was worse than before. Now it
> | needs to spill more registers when compiling the same source code.
> 
> In what way is the intermediate code awful? 

Because the error message from the register allocator tells us that there are over 1000 live variables at a particular point the assembly code, but the "biggest" SHA hashing algorithm (SHA-3) should only need to maintain 25 words of state (says Wikipedia).


> How could it be fixed?


Someone that cares enough about the SHA library would need to understand why it's producing the intermediate code it does. My gentle suggestion is that when a library developer starts adding INLINE pragmas to their program it becomes their job to understand why the intermediate code is how it is.


> Worth opening a ticket for that issue?  At the moment it's invisible because the issue appears superficially to be about register allocation.

I'd open a ticket against the SHA library saying the choice of optimisation flags / pragmas is probably causing code explosion during compilation. If the developer then decides this is really a problem in GHC I'd want some description of what core transforms they need to happen to achieve good performance. The strategy of "inline everything and hope for the best" is understandable (I've used it!) but only gets you so far...

The bug report is like someone saying "GHC can't compile my 100MB core program". You can either open a ticket against GHC, or ask "why have you got a 100MB core program?"

Ben.