[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