[cfe-dev] Smart Pointer Lifetime Optimizations

[John McCall via cfe-dev]

On 10 Jun 2020, at 11:31, Arthur O'Dwyer wrote:

> On Wed, Jun 10, 2020 at 11:14 AM Johannes Doerfert via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> On 6/8/20 8:13 PM, Richard Smith via cfe-dev wrote
>>>> You wouldn’t be the first person to be surprised by the result of 
>>>> this
>> sort
>>>> of analysis, but I’m afraid it’s what we’re working with.
>>>>
>>>> Unfortunately, there’s really no way to eliminate this one 
>>>> without
>> either
>>>> interprocedural information or language changes. trivial_abi 
>>>> eliminates
>>>> the other one because it changes the convention for passing by 
>>>> value,
>> but
>>>> to pass an “immutably borrowed” value in C++ we have to pass by
>> reference,
>>>> which allows the reference to be escaped and accessed (and even
>> mutated, if the
>>>> original object wasn’t declared const) as long as those accesses 
>>>> happen
>>>> before destruction.
>>>>
>>> Perhaps we should expose LLVM's nocapture attribute to the source 
>>> level?
>>
>> Yes please ;)
>>
>
> As someone (John?) has said in this thread, the nocapture attribute is
> already exposed to C/C++ via __attribute__((noescape)).
>
> Here is an example of __attribute__((noescape)) doing its thing:
> https://godbolt.org/z/rJbEmZ
> In function `one`, the call to `noargs` is assumed to trash the value 
> of
> `i`.
> In function `two`, the call to `noargs` is *not* assumed to trash the 
> value
> of `i`.
>
> 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 *cannot assume that its 
> value is
> unchanged by that call*. This is required by C++'s loose rules around
> `const`. But it doesn't match up with human intuition very well.
>
> 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 *assume* 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.

This is quite an interesting idea.  Having a mode that assumes that
`const` references don’t get cast back might be quite interesting.  I
suspect that enforcing stricter escape rules would break some specific
idioms and types.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200610/f18ba5aa/attachment.html>