> On Mon, Mar 19, 2012 at 12:12 PM, Simon Marlow <[email protected]> > wrote: > > I've been thinking a little about this. If some extension to LLVM is > needed to support TNTC, then I think it might be better to go all the way > and support arbitrary labels with info tables, not just top-level > procedures. Also, it has to be possible to take the address of a > label. Obviously, such labels cannot be optimised away, and there has to > be enough information in the intermediate code to be able to construct > control-flow graphs. > > Now that you have stated it, this approach sounds like the right one. > > Do I get it right that we could place such a label at the end of the info > table and thus get the proper TNTC?
Right, this is a superset of TNTC, extending it to all labels, not just the top-level procs. > > We can make the NCG support arbitrary labels with info tables quite > easily, and I'm very tempted to do it because it will let us generate much > better code. But the LLVM route will not be able to benefit, unless we > can find a way to do this with LLVM too. > > Do you think the LLVM developers would accept such an extension if we > suggest this to them explicitly? I'm afraid they won't be very happy with > it. Actually, it is not a big step from what LLVM 2.7 already supports in the form of address-taken labels. I just re-read this blog post that David linked to a while back: http://blog.llvm.org/2010/01/address-of-label-and-indirect-branches.html LLVM's blockaddress nodes correspond directly to CmmBlock in the new Cmm. Now, the difference comes when we want to translate something like call Sp[0] returns to L into LLVM. LLVM provides a way to do an indirect branch with the indirectbr instruction, which lists all the labels it can potentially branch to. But we need something slightly different: we want to make a tail call (passing parameters etc.) that at some point in the future will jump back to L. How hard it is to add this to LLVM I don't know. The main difficulty is probably that L must have the same entry convention as a top-level LLVM proc. Cheers, Simon _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
