[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
arguments).
> 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
though...
> 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. :)
-Chris
--
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/
More information about the llvm-dev
mailing list