<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Feb 24, 2016 at 7:34 PM Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On 2016-Feb-24, at 19:17, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:<br>
><br>
> On Wed, Feb 24, 2016 at 7:10 PM Sanjoy Das via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> On Wed, Feb 24, 2016 at 6:51 PM, Duncan P. N. Exon Smith<br>
> <<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>> wrote:<br>
> >> If we do not inline @foo(), and instead re-link the call site in @main<br>
> >> to some non-optimized copy (or differently optimized copy) of @foo,<br>
> >> then it is possible for the program to have the behavior {print("Y");<br>
> >> print ("X")}, which was disallowed in the earlier program.<br>
> >><br>
> >> In other words, opt refined the semantics of @foo() (i.e. reduced the<br>
> >> set of behaviors it may have) in ways that would make later<br>
> >> optimizations invalid if we de-refine the implementation of @foo().<br>
> ><br>
> > I'm probably missing something obvious here.  How could the result of<br>
> > `%t0 != %t1` be different at optimization time in one file than from<br>
> > runtime in the "real" implementation?  Doesn't this make the CSE<br>
> > invalid?<br>
><br>
> `%t0` and `%t1` are "allowed" to "always be the same", i.e. an<br>
> implementation of @foo that always feeds in the same<br>
> value for `%t0` and `%t1` is a valid implementation (which is why the<br>
> CSE was valid); but it is not the *only* valid implementation.  If I<br>
> don't CSE the two load instructions (also a valid thing to do), and<br>
> this is a second thread writing to `%par`, then the two values loaded<br>
> can be different, and you could end up printing `"X"` in `@foo`.<br>
><br>
> Did that make sense?<br>
<br>
Yes.  To be sure I understand the scope: this is only a problem for<br>
atomics, correct?  (Because multi-threaded behaviour with other globals<br>
is UB?)<br>
<br>
> > Does linkonce_odr linkage have the same problem?<br>
> > - If so, do you want to change it too?<br>
> > - Else, why not?<br>
><br>
> Going by the specification in the LangRef, I'd say it depends on how<br>
> you define "definitive".  If you're allowed to replace the body of a<br>
> function with a differently optimized body, then the above problem<br>
> exists.<br>
><br>
> I believe that is the case, and I strongly believe the problem you outline exists for linkonce_odr exactly as it does for available_externally.<br>
><br>
> Which is what makes this scary: every C++ inline function today can trigger this.<br>
<br>
Every C/C++ inline or template function.  But only the ones that use<br>
atomics, right?<br></blockquote><div><br></div><div>Well, with *this* example...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Not that I'm sure that will end up being a helpful distinction.<br></blockquote><div><br></div><div>Right. See Richard's comment. I think that sums up the real issue here. =/</div></div></div>