[llvm-dev] sret read after unwind

[Johannes Doerfert via llvm-dev]

On 1/5/22 07:41, Nikita Popov wrote:
>> Maybe I am confused but I thought something like this pseudo-code
>> could be optimized, readonly_on_return is similar.
>>
>> ```
>> int a = 42;
>> invoke foo(/* readonly_on_unwind */ &a);
>> lp:
>>     return a; // a == 42
>> cont:
>>     return a; // a unknown
>> ```
>>
> Okay, I guess there's a possible point of confusion here: The intention
> here is that the attribute encodes a requirement on accesses *after* the
> call. readonly_on_unwind would allow only reading "a" in "lp", but does not
> prevent foo() from modifying "a" even if it ultimately unwinds. With that
> in mind, I don't think the attribute would enable any additional
> optimization here.
>
> So maybe the proposed attribute is better named as "noreadafterunwind"
> rather than "noreadonunwind".

So I misunderstood the entire idea :D

I am not sure how I feel about such a new "category" of attributes.
Can we try to throw around some ideas before we commit to it?

One of the weirdest things is that the semantics are somewhat
described in terms of the caller. Making it callee-centric might
help, e.g., `poison_on_unwind(%a)` to indicate the value in the
unwind case is "not read" or rather, replaced with poison.

You noted in the other mail that we don't want to make unwind paths
explicit (which I agree with, FWIW). However, in the caller we already
have them explicitly, no? So what materializing the "virtual memset"/
lifetime.end stuff there? Frontends (like Rust) can do it based on the
callee type so that should not be a problem.

Thoughts?

~ Johannes


>
> Regards,
> Nikita
>