LLVM optimisation passes / tables next to code
simonmar at microsoft.com
Thu Mar 22 10:44:03 CET 2012
> On Mon, Mar 19, 2012 at 12:12 PM, Simon Marlow <simonmar at microsoft.com>
> > 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
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:
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 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.
More information about the Cvs-ghc