[cfe-dev] Smart Pointer Lifetime Optimizations

[Johannes Doerfert via cfe-dev]

On 6/10/20 12:36 PM, John McCall wrote:
>
>
> 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.
>

Agreed. There are no doubt use cases though. I remember the one vendor 
compiler

that offered a flag to make *all* arguments restrict. It for sure breaks 
code,

but some seemed to really like it. There is also the option to only 
"apply" these

to user code, not system includes (assuming we can reasonably 
differentiate).


-- Johannes