[llvm-commits] patch: target option to disable tail calls

[Nick Lewycky]

On 18 January 2012 16:13, Eli Friedman <eli.friedman at gmail.com> wrote:

> On Wed, Jan 18, 2012 at 4:02 PM, Nick Lewycky <nlewycky at google.com> wrote:
> > On 18 January 2012 15:25, Eli Friedman <eli.friedman at gmail.com> wrote:
> >>
> >> On Wed, Jan 18, 2012 at 3:10 PM, Nick Lewycky <nlewycky at google.com>
> wrote:
> >> > The attached patch adds a new "-no-tail-calls" flag to llc, and
> >> > implements
> >> > it in the x86 backend only. The intent is to support gcc's
> >> > -fno-optimize-sibling-calls in clang, which as far as I can tell just
> >> > disables tail calls period. The goal is to help ASAN produce correct
> >> > stack
> >> > traces, which requires disabling all tail calls.
> >> >
> >> > As an aside, there is a good reason to do this in the backend and not
> at
> >> > the
> >> > IR-level. The "tail" marker is used to indicate things that are useful
> >> > to
> >> > the optimizers themselves; for example alias analysis interprets the
> >> > presence of a tail marker as proof that the callee can't access any
> >> > alloca's
> >> > in the caller, whether the pointer has been captured or not.
> >>
> >> You're right that expressing this constraint with the tail marker
> >> doesn't make sense; that said, why not a function attribute?
> >
> >
> > Hunh? Why would you want to set this per-function? This is similar to
> > choosing (codegen) optimization levels or an ABIs, or other similar
> codegen
> > issues.
> >
> > For my use-case, I want all functions to be built this way.
>
> Another thing to think about is "does it make sense for LTO to mix two
> modules with different specifications for this option".  But from what
> you're saying, it sounds like that doesn't really make sense, so it's
> fine.
>

I'm willing to sign up for some LTO-driven attribute cleanup some day, but
since there are no available bits at the moment, I'm going to go ahead and
submit this as-is.

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120118/dd2c6b89/attachment.html>