[cfe-dev] Smart Pointer Lifetime Optimizations

[Johannes Doerfert via cfe-dev]

On 6/10/20 10:31 AM, 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)).
>
Yeah, I saw that later, thanks. I actually want way more attributes exposed,

e.g., the ones I mention below. But also `dereferenceable`, `nosync`,

`willreturn`, ...



> 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.

Interesting, especially to determine lost performance potential [0].

Should not even be hard, mark `const` as `nocapture`, `readonly`,

and `nofree` during IR-gen.


-- Johannes


[0] https://link.springer.com/chapter/10.1007/978-3-030-20656-7_13


> –Arthur
>