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.
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
