New codegen: CmmStackLayout igraph memory explosion
Filing this as a ticket because I don't have time to investigate. On compiler performance test T3294, with the new code generator, we see a dramatic spike in allocations due to the igraph function. Looks like the algorithm doesn't like data types with lots and lots of constructors!
Here is the textual profile:
Tue Apr 26 17:55 2011 Time and Allocation Profiling Report (Final)
ghc-stage2 +RTS -p -RTS -B/home/ezyang/Dev/ghc-build-master-stage2-prof/inplace/lib -pgmc /usr/bin/gcc -pgma /usr/bin/gcc -pgml /usr/bin/gcc -pgmP /usr/bin/gcc -E -undef -traditional -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -c T3294.hs
total time = 34.74 secs (1737 ticks @ 20 ms)
total alloc = 7,892,000,312 bytes (excludes profiling overheads)
COST CENTRE MODULE %time %alloc
addToUFM UniqFM 8.0 14.9
dataflowPassFwd Cmm 7.2 10.0
foldUFM_Directly UniqFM 5.5 7.4
slotLattice CmmStackLayout 5.2 4.4
conflictSlots CmmStackLayout 4.0 7.1
igraph CmmStackLayout 3.8 2.4
ufmToList UniqFM 3.4 7.8
dataflowPassBwd Cmm 3.4 4.6
sLit FastString 1.8 0.1
layLeft Pretty 1.8 1.5
MAIN MAIN 1.7 0.0
dopt DynFlags 1.7 0.0
mkUniqueGrimily Unique 1.7 1.3
textBeside_ Pretty 1.3 1.9
lattice CmmProcPoint 1.3 0.1
areaBuilder CmmStackLayout 1.3 0.9
bPutStr BufWrite 1.3 0.4
allocRegsAndSpill_spill RegAlloc.Linear.Main 1.3 0.4
countUses CmmOpt 1.3 0.6
genRaInsn RegAlloc.Linear.Main 1.0 1.0
lookForInline' CmmOpt 1.0 0.3
iBox FastTypes 1.0 2.6
writeFastMutInt FastMutInt 0.7 1.6
readFastMutInt FastMutInt 0.7 1.7
aboveNest Pretty 0.7 1.4
<> Pretty 0.6 1.1
foldRightWithKey FiniteMap 0.6 1.1
And I will attach a more informative hp2ps heap profile.
Trac metadata
Trac field | Value |
---|---|
Version | 7.1 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Compiler |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |