[llvm-commits] [llvm] r41804 - in /llvm/trunk: lib/Transforms/Scalar/TailRecursionElimination.cpp test/Transforms/TailCallElim/inf-recursion.ll

[Chris Lattner]

On Sep 10, 2007, at 5:08 PM, Dale Johannesen wrote:

> On Sep 10, 2007, at 4:53 PM, Chris Lattner wrote:
>>> Can't we
>>> detect whether the call is going to be lowered
>>> to inline code and disable the transformation only in that case?
>>
>> To be honest, I'm not really very happy with this approach (disabling
>> tail recursion from the entry block), it's quite a hack.  However, I
>> can't think of a good way to handle this: one possibility would be to
>> add a new "is a builtin" attribute, and attach it to the call, but
>> that is gross in its own way.
>>
>> -Chris
>
> Well, it is, but the optimizers really should know which are the
> builtins; some of them have special semantics.

Well I agree to some extent.  The problem is that the compiler treats  
functions like "fabs" as builtins, regardless of whether they are  
written as "__builtin_fabs" or "fabs".  This argues for having an  
attribute on the functions, which would also make it easier to handle  
things like -fno-builtins and -fno-builtin-abs.

The problem with this is that it requires the front-end to know all  
of the builtins recognized by the optimizers and code generator,  
which is it's own issue.

> Perhaps builtins should not be marked as tail calls?

This won't work: tailcallelim is the one that infers the tail marker  
in most cases.  The tail marker is a confusingly named marker that  
indicates that the callee doesn't access the caller's stack frame.   
It doesn't have anything to do with tailcallelim persay except being  
a required-but-not-sufficient property.

-Chris