Hi Simon, Thanks for the response. I have a few comments below.
On Mar 17, 2010, at 7:25 AM, Simon Marlow wrote: > On 15/03/2010 18:35, David Peixotto wrote: >> 1) Does it still make sense to pursue these optimizations in the native >> code generator? > > Well, this transformation is something that would be done earlier than the > native code generator, probably as part of the STG->C-- phase or in one of > the phases that follows it. It's important that we still do transformations > like these in GHC, even if in some cases LLVM can figure out how to get the > same results on its own, because in general we have more information than > LLVM and can make more informed decisions. A good example of this is the > fact that in GHC we know that stack and heap addresses cannot alias, whereas > LLVM cannot know that (is there a way to tell it?). Yes, I should have been more precise here. I was thinking of this as a Cmm -> Cmm optimization pass. It sounds like the kinds of optimizations to focus on are where we can provide extra information to the low-level optimizer that is difficult to prove using standard compiler analyses. Presumably we could pass info to LLVM by writing custom analysis passes and doing the analysis based on naming conventions (for example saying the addresses in the HP and SP regs do not alias) or by reading some serialized data produced during the lowering passes inside GHC. One area where LLVM may have an advantage is doing link-time optimization. I believe there may be some optimization opportunities that would be exposed by operating on both the user code and runtime code together. Would it be possible to do this in GHC as well? For example, could we make the Cmm code that is written for the runtime available to the Cmm optimizer so that it could potentially inline functions from the runtime into user code? Doing this would get GHC closer to what LLVM could do, but I think LLVM still would have the advantage here because it could also expose all of the runtime code written in C. >> Given the strong optimizations already in LLVM is it worth investing >> time in the GHC native backend? > > It's probably not worth investing a lot of time in optimisations that affect > only the native backend, no. So, for example, you would see things like more powerful register allocators, instruction scheduling, instruction selection, etc. be pushed off to LLVM. >> 2) What is the definition of a safe point for the GC? > > Safe points are constructed, rather than identified. To make a safe point, > everything live has to be saved on the stack, and there needs to be a return > point with an info table describing the stack frame layout. I believe the > new code generator makes this more convenient to arrange than it was > previously. I see, this makes more sense to me now. I was slightly confused by an earlier statement you made[1] which made me think that there was some other outside invariants that had to be met. You had said (over 2 years ago now): "a heap check can only occur at a safe point, which is the top of the basic block. So we can push the heapcheck in as long as we don't push it past any dangerous operations, like a side-effecting foreign call, for example (the call would be repeated after the GC had run)." If the new code generator allows for more flexibility in placing these heap checks then we should be able to do this optimization (and it sounds like Simon Peyton-Jones already has an idea about how he wants to do it). Thanks, Dave [1] http://www.haskell.org/pipermail/cvs-ghc/2007-July/036514.html _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
