[LLVMdev] How to handle nested procedures?

Jeff Cohen jeffc at jolt-lang.org
Sun Aug 22 10:34:58 PDT 2004


On Sat, 21 Aug 2004 20:35:35 -0500
"Patrick Meredith" <pmeredit at uiuc.edu> wrote:

> 
> ----- Original Message ----- 
> From: "Jeff Cohen" <jeffc at jolt-lang.org>
> To: <LLVMdev at cs.uiuc.edu>
> Sent: Saturday, August 21, 2004 7:35 PM
> Subject: [LLVMdev] How to handle nested procedures?
> 
> 
> > How would following Pascal code be translated to LLVM?
> >
> >   procedure outer(a: integer): integer;
> >     procedure inner(b: integer): integer;
> >     begin
> >       return a + b
> >     end;
> >   begin
> >     return inner(a)
> >   end;
> >
> > If outer(10) is called, it returns 20.
> >
> > The problem here is that inner has access to the locals and formal
> > arguments of outer.  I do not see any direct support for this.  It could
> > be handled by creating a struct for outer that contains everything used
> > by inner procedures and explicitly passing its address to the inner
> > procedures as an extra parameter.
> 
> There is no need for support of this, keep in mind that normal Pascal
> compilers translate to local assembly code which also does not support inner
> functions.  The struct idea is probably a good LLVM way to do it.  In a
> normal compiler you would use displays or access links, which basically
> consist of having some way to refer to the stack frame of a parent function.
> The struct would be acheiving the same thing.

I was concerned that if the optimizer inlined inner, it would not be
able to eliminate all the overhead introduced by this scheme.  So I ran
a test.  I simulated the above with the following C code:

struct FRAME { int a; };

static int inner(struct FRAME* frame, int b) {
        return frame->a + b;
}

int outer(int a) {
        struct FRAME frame;
        frame.a = a;
        return inner(&frame, a);
}

This produces:

int %outer(int %a) {
entry:
	%tmp.4.i = shl int %a, ubyte 1		; <int> [#uses=1]
	ret int %tmp.4.i
}

Function inner isn't even emitted (no doubt a consequence of being
static, as an inner method shouldn't have external visibility).  I can't
complain :-)




More information about the llvm-dev mailing list