On 28/12/13 03:58, Ben Lippmeier wrote:
On 27/12/2013, at 12:07 PM, Kazu Yamamoto (山本和彦) wrote:
Hi,
When I tried to build the SHA library with GHC head on on 32bit Linux,
GHC head got panic. GHC 7.4.2 can build SHA on the same machine.
Configuring SHA-1.6.1...
Building SHA-1.6.1...
Failed to install SHA-1.6.1
Last 10 lines of the build log (
/home/kazu/work/rpf/.cabal-sandbox/logs/SHA-1.6.1.log ):
Preprocessing library SHA-1.6.1...
[1 of 1] Compiling Data.Digest.Pure.SHA ( Data/Digest/Pure/SHA.hs,
dist/dist-sandbox-ef3aaa11/build/Data/Digest/Pure/SHA.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.7.20131202 for i386-unknown-linux):
regSpill: out of spill slots!
regs to spill = 1129
slots left = 677
There are only a fixed number of register spill slots, and when
they're all used the compiler can't dynamically allocate more of
them.
Not true any more in 7.8+ with the linear allocator. I think it might
still be true for the graph allocator, which is sadly suffering from a
little bitrot and probably doesn't generate very good code with the new
code generator.
So, avoiding -fregs-graph should work around this with 7.8.
Cheers,
Simon
This SHA benchmark is pathological in that the intermediate code expands to
have many variables with long, overlapping live ranges. The underlying problem
is really that the inliner and/or other optimisations have gone crazy and made
a huge intermediate program. We *could* give it more spill slots, to make it
compile, but the generated code would be horrible.
Try turning down the optimisation level, reduce inliner keenness, or reduce
SpecConstr flags.
Ben.
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
