<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Wed, Jun 10, 2020 at 11:14 AM Johannes Doerfert via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
On 6/8/20 8:13 PM, Richard Smith via cfe-dev wrote<br>
>> You wouldn’t be the first person to be surprised by the result of this sort<br>
>> of analysis, but I’m afraid it’s what we’re working with.<br>
>><br>
>> Unfortunately, there’s really no way to eliminate this one without either<br>
>> interprocedural information or language changes. trivial_abi eliminates<br>
>> the other one because it changes the convention for passing by value, but<br>
>> to pass an “immutably borrowed” value in C++ we have to pass by reference,<br>
>> which allows the reference to be escaped and accessed (and even mutated, if the<br>
>> original object wasn’t declared const) as long as those accesses happen<br>
>> before destruction.<br>
>><br>
> Perhaps we should expose LLVM's nocapture attribute to the source level?<br>
<br>
Yes please ;)<br></blockquote><div><br></div><div>As someone (John?) has said in this thread, the nocapture attribute is already exposed to C/C++ via __attribute__((noescape)).</div><div><br></div><div>Here is an example of __attribute__((noescape)) doing its thing:</div><div><a href="https://godbolt.org/z/rJbEmZ">https://godbolt.org/z/rJbEmZ</a><br></div><div>In function `one`, the call to `noargs` is assumed to trash the value of `i`.</div><div>In function `two`, the call to `noargs` is <b><i>not</i></b> assumed to trash the value of `i`.</div><div><br></div><div>However, notice that the store corresponding to the assignment `i = 42;` cannot be removed in either case!  We initialize `i` to 42, then pass it by const reference to `dont_escape`, and yet <i>cannot assume that its value is unchanged by that call</i>. This is required by C++'s loose rules around `const`. But it doesn't match up with human intuition very well.</div><div><br></div><div>I mentioned to Zoe offline that I'd like to see Clang add an opt-in non-conforming optimization mode, on the lines of `-ffast-math`, which would <i><b>assume</b></i> things like "things passed by const reference don't change" and "things passed by reference don't escape," and then measure to what degree codegen is improved on real codebases by that non-conforming optimization mode.</div><div><br></div><div>–Arthur</div></div></div></div></div>