<div class="gmail_quote">On 18 January 2012 16:13, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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

<div><br></div><div>Nick</div><div><br></div></div>