#7198: New codegen more than doubles compile time of T3294 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #4258 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by michalt): So I was trying to learn more about the codegen using this ticket as the motivation and I think I’m missing something. I was looking at modifying `StgCmmBind.thunkCode` where we unconditionally load all the free variables into registers (before generating the code for the body of the thunk). Instead, I thought we could simply populate the environment with expressions containing the right memory accesses (using `addBindC`). My thinking was that: `node` is already a local register (so shouldn’t change), so anything relative to it should be stable and thus safe to use. Unfortunately, this segfaults `ghc-stage2` (i.e., `ghc- stage1` creates something bad). :-/ I tried using `devel1` flavor but that didn't help find anything (i.e., no assertion failures). Trivial programs compiled by `ghc-stage1` seem to work. So it seems that GHC is large enough to trigger some silly bug in my code, but I’m a bit stuck at what that might be. Any ideas what I’m missing? I’m happy to dig further if you have no ideas (or time), but thought I’d ask if there’s something that’s obviously wrong with the idea or code. Thanks! Code: https://github.com/michalt/ghc/tree/t7198/1 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7198#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler