I'm seeing a different, but related, error:
ghc: panic! (the 'impossible' happened)
(GHC version 6.11.20081209 for x86_64-unknown-linux):
CoreToStg.myCollectArgs
(__scc {trivColorable ghc-6.11.20081209:MachRegs !}
ghc-6.11.20081209:MachRegs.isSqueesed{v ra} [gid] 0 0)
eta_s2J6{v} [lid]
This happens because CoreToStg sees this code:
let {
sat_s2J3 :: UniqFM.UniqFM MachRegs.Reg
-> (# GHC.Bool.Bool, GHC.Prim.Int#, GHC.Prim.Int# #)
[]
sat_s2J3 =
\ (eta_s2J6 :: UniqFM.UniqFM MachRegs.Reg) ->
(__scc {trivColorable ghc-6.11.20081209:MachRegs !}
MachRegs.isSqueesed 0 0)
eta_s2J6 } in
which is not in A-normal form. I wonder whether doing eta-expansion later
in CorePrep is breaking some invariants? Indeed it does contradict the
comment in CorePrep (see Note [eta expansion]):
--
NB3: It's important to do eta expansion, and *then* ANF-ising
f = /\a -> g (h 3) -- h has arity 2
If we ANF first we get
f = /\a -> let s = h 3 in g s
and now eta expansion gives
f = /\a -> \ y -> (let s = h 3 in g s) y
which is horrible.
Eta expanding first gives
f = /\a -> \y -> let s = h 3 in g s y
--
Indeed, this is similar to what is happening in my panic above.
Cheers,
Simon
Simon Peyton-Jones wrote:
FWIW, I found a few mins to understand this problem a bit more.
SCCfinal assumes that CorePrep produces something like this
x = \y1..yn. scc "foo" body
(See slurpSCCs in line237-ish of SCCfinal.)
But CoreUtils.eta_expand produces something more like
x = scc "foo" (\y1..yn. body)
And eta expansion is (now) done last by CorePrep, so the deLam call on line 399
of CorePrep doesn't get a chance to fire. And a good thing really, because it
would generate inefficient code.
Various possible solutions:
- In CoreToStg, attach any outer scc's to the StgRhsClosure
This could be done in mkStgRhs. There is a suitable field
in the StgRhsClosure. The downside is that this overlaps a bit
with slurpSCCs in SCCfinal.
- At the eta expand call in CorePrep, push the SCCs inside the lambdas,
from where SCCfinal can slurp them out again. I don't really like this.
Anyway I hope this makes it a bit clearer.
Simon
| -----Original Message-----
| From: Simon Marlow [mailto:[EMAIL PROTECTED] On Behalf Of Simon
| Marlow
| Sent: 09 December 2008 10:05
| To: Thomas Schilling
| Cc: Simon Peyton-Jones; cvs-ghc@haskell.org
| Subject: Re: Panic when building head with profiling
|
| Thomas Schilling wrote:
| > Ok, rebuilding from scratch doesn't help. The message is almost the
| > same, though the file may be obscured due to make -j3. With just make
| > the actual failure is (unsurprisingly) in
| > dist-stage2/build/BinIface.p_hi.
| >
| > Apparently there's a do_expr case missing for StgLam in
| > stgMassageForProfiling, but I could only guess how this could look
| > like or whether this should perhaps never occur and be converted to a
| > closure or an StgLet somewhere.
| >
| > 2008/12/8 Thomas Schilling <[EMAIL PROTECTED]>:
| >> That seems to have fixed one problem, but I now get:
| >>
| >> <<ghc: 89630452 bytes, 7 GCs, 3328000/6496256 avg/max bytes residency
| >> (2 samples), 65M in use, 0.00 INIT (0.00 elapsed), 0.27 MUT (0.63
| >> elapsed), 0.08 GC (0.11 elapsed) :ghc>>
| >> /Users/nominolo/code/ghc/ng-api/ghc/stage1-inplace/ghc
| >> -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -package-name ghc-6.11.20081205
| >> -hide-all-packages -no-user-package-conf -i -idist-stage2/build
| >> -inativeGen -ibasicTypes -icmm -icodeGen -icoreSyn -icprAnalysis
| >> -ideSugar -ighci -ihsSyn -iiface -imain -iparser -iprelude -iprofiling
| >> -irename -isimplCore -isimplStg -ispecialise -istgSyn -istranal
| >> -itypecheck -itypes -iutils -ivectorise -idist-stage2/build/autogen
| >> -Idist-stage2/build/autogen -Idist-stage2/build
| >> -I../libffi/build/include -Istage2plus -I../libraries/base/cbits
| >> -I../libraries/base/include -I. -Iparser -Iutils -optP-DUSE_EDITLINE
| >> -optP-DGHCI -optP-include
| >> -optPdist-stage2/build/autogen/cabal_macros.h -odir dist-stage2/build
| >> -hidir dist-stage2/build -stubdir dist-stage2/build -package
| >> Cabal-1.5.5 -package array-0.2.0.0 -package base-4.0.0.0 -package
| >> bytestring-0.9.1.4 -package containers-0.2.0.0 -package
| >> directory-1.0.0.2 -package editline-0.2.1.0 -package filepath-1.1.0.1
| >> -package haskell98-1.0.1.0 -package hpc-0.5.0.2 -package
| >> old-time-1.0.0.1 -package process-1.0.1.1 -package
| >> template-haskell-2.3.0.0 -package unix-2.3.1.0 -O -Wall
| >> -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash
| >> -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface
| >> -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses
| >> -XFlexibleInstances -XRank2Types -XScopedTypeVariables
| >> -XDeriveDataTypeable -prof -hisuf p_hi -hcsuf p_hc -osuf p_o
| >> -idist-stage2/build -H64m -O -fasm -W -fno-warn-unused-matches
| >> -fwarn-unused-imports -Rghc-timing -Rghc-timing -O0 -DDEBUG -c
| >> cmm/CmmProcPointZ.hs -o dist-stage2/build/CmmProcPointZ.p_o -ohi
| >> dist-stage2/build/CmmProcPointZ.p_hi
| >> ghc: panic! (the 'impossible' happened)
| >> (GHC version 6.11.20081205 for i386-apple-darwin):
| >> SCCfinal.do_expr
| >> \ [eta_s9gV{v} [lid]] ->
| >> ghc-6.11.20081205:Binary.a74{v r2Y} [gid]
| >> $dBinary37{v r7mT} [gid] bh{v s9fY} [lid] eta_s9gV{v} [lid]
|
| I don't know what caused this, but it appears that SCCfinal has encountered
| an StgLam. This isn't supposed to happen, because according to the
| comments in StgSyn:
|
| -- StgLam is used *only* during CoreToStg's work. Before CoreToStg has
| finished
| -- it encodes (\x -> e) as (let f = \x -> e in f)
|
| Cheers,
| Simon
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
