[LLVMdev] repeated recursion with "frozen" arguments

Chris Lattner sabre at nondot.org
Tue Aug 26 16:31:00 PDT 2003


> CL> Probably not, at least not in the near future.  At some point I have had
> CL> thoughts about implementing a tail recursion pass, but without prior
> CL> transformation, this function would not be a candidate.
>
> wait... if you break this C-example at the place as you did then it is
> absolutely not what I have meant. Indeed, sense of my example comes
> iff the top-level call is given, i.e. it might be optimized in
> the context of concrete external call.

Yup, I think I completely missed your point.  :)

> generally you are right. But only generally :)
> In particular, my example showed a feature of typical lexical closure.

Can you explain more about what you mean.  I don't think I understand.

> CL> In terms of LLVM you could certainly do this.  For example you could
> CL> translate it to use an explicit stack:

> then I have to dig LLVM docs about explicit stack :)

I just mean you have an explicit stack data structure to store just the
elements the recursive call needs.

> CL> Sure, but you still need the 'this' pointer, to know WHICH valarray you
> CL> are talking about... ?
>
> sure. But what if this `this' was set once for 1mio calls?
> Today I have a lot heavy math function working with two spectra and
> every time I have to think twice before making another member function
> which is invoked in deeper stack frames.

varray's do not have any recursive function calls, and the methods tend to
be simple.  For that reason, they are typically all inlined, eliminating
the parameter passing completely...

> In other words, just imagine the situation, when for a given object
> really a lot of *its* members function are called without changing
> `this'. Today compilers can't eliminate this _extra_ `this'. And real
> C++ code has tendency to be slower.

I really am not sure I understand what transformation you are proposing.
Can you elaborate more?  :)

Thanks,

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/




More information about the llvm-dev mailing list