[LLVMdev] repeated recursion with =?koi8-r?Q?=22?=frozen=?koi8-r?Q?=22=20?=arguments

Chris Lattner sabre at nondot.org
Wed Aug 27 09:16:01 PDT 2003

On Wed, 27 Aug 2003, [koi8-r] "÷ÁÌÅÒÉÊ èÁÍÅÎÑ"  wrote:
> funny, that if even so, I got two similar and concrete
> answers already:
> "it is suitable for LLVM, though not implemented yet"
> :)


> S2. Theoretically this redundant copy might be eliminated.
>     The idea is simple: at first (i.e. non-recursive) call
>     generate `rec_func' code which does not push `x' on
>     the stack because it will remain the same from the
>     first non-recursive call. For example initial
>     non-recursive call `rec_func(1, 1000)' should be
>     instantiated as:

Ok, Vikram is right.  This is known as procedure cloning, where the
compiler makes a specialized version of the function for an invocation
with constant arguments (thus making it so you don't have to pass the

> S3. This example is just a C-analogy of how pushing `this'
>     onto stack might be eliminated. Just think of `x' as
>     it would be `this', and think of `rec_func' as it
>     would be a non-static member function. For example:

Ok, I see why I was confused here.  The problem is that a particular
"this" is not, in general, a compile time constant: if the object is
allocated dynamically on the stack or heap, the static compiler doesn't
know which value to specialize with.  Obviously a dynamic compiler could

> S4. in optimization of C-example (see S2.) we just made a
>     lexical closure in respet to variable `x'. (And by analogy,
>     in C++ example we could consider similar optimization which
>      in a sense is a lexical closure in respect to `this')

Ok, I understand now.  When I think of lexical closures, I think if a
piece of memory which holds the variables used by a block of code, coupled
with a generic version of the code.  Converting a "this" pointer to use
this style of closure means that you have to add a closure pointer  :)

So, in sum, yes, LLVM is a good representation to do this kind of thing
on.  :)



More information about the llvm-dev mailing list