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 _______________________________________________ llvm-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
