LLVM optimisation passes / tables next to code

[Simon Marlow]

> On Mon, Mar 19, 2012 at 12:12 PM, Simon Marlow <simonmar at microsoft.com>
> 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