SHA1.hs woes, was Version control systems

[Ben Lippmeier]

On 19/08/2008, at 8:57 PM, Ian Lynagh wrote:

> On Mon, Aug 18, 2008 at 09:20:54PM +1000, Ben Lippmeier wrote:
>>
>> Ian: Did this problem result in Intel CC / GCC register allocator
>> freakouts?
>
> Have you got me confused with someone else? I don't think I've ever  
> used
> Intel CC.
>

Sorry, I couldn't find the rest of the preceding message. Someone  
wrote that they had to turn down cc flags to get SHA1.hs to compile on  
IA64.

What C compiler was being used, and what were the symptoms?

SHA1.hs creates vastly more register pressure than any other code I  
know of (or could find), but only when -O or -O2 is enabled in GHC. If  
-O and -prof are enabled then the linear allocator runs out of stack  
slots (last time I checked).

I'm wondering three things:

1) If the C compiler could not compile the C code emitted by GHC then  
maybe we should file a bug report with the CC people.

2) If the register pressure in SHA1.hs is more due to excessive code  
unfolding than the actual SHA algorithm, then maybe this should be  
treated as a bug in the simplifier(?) (sorry, I'm not familiar with  
the core level stuff)

3) Ticket #1993 says that the linear allocator runs out of stack  
slots, and the graph coloring allocator stack overflows when trying to  
compile SHA1.hs with -funfolding-use-threshold20. I'm a bit worried  
about the stack over-flow part.

The graph size is O(n^2) in the number of vreg conflicts, which isn't  
a problem for most code. However, if register pressure in SHA1.hs is  
proportional to the unfolding threshold (especially if more than  
linearly) then you could always blow up the graph allocator by setting  
the threshold arbitrarily high.

In this case maybe the allocator should give a warning when the  
pressure is high and suggest turning the threshold down. Then we could  
close this issue and prevent it from being re-opened.

Cheers,
	Ben.