[PATCH] D109548: Make llvm.launder.invariant.group writeonly

[Piotr Padlewski via Phabricator via llvm-commits]

Prazek added a comment.

In D109548#2996145 <https://reviews.llvm.org/D109548#2996145>, @nikic wrote:

> In D109548#2995597 <https://reviews.llvm.org/D109548#2995597>, @aeubanks wrote:
>
>> In D109548#2995551 <https://reviews.llvm.org/D109548#2995551>, @jdoerfert wrote:
>>
>>> In D109548#2995532 <https://reviews.llvm.org/D109548#2995532>, @aeubanks wrote:
>>>
>>>> In D109548#2994483 <https://reviews.llvm.org/D109548#2994483>, @nikic wrote:
>>>>
>>>>> @Prazek `writeonly` only says that no memory is read, it does not determine which location is actually written. `launder.invariant.group`does not read or write the pointer operands (it is inaccessiblememonly), it "writes" some inaccessible location to avoid code motion optimizations. To perform DSE, we need to know the location being written.
>>>>
>>>> If a `writeonly` function is called multiple times, can it can only write a constant to a constant location or the argument? To be able to write to different locations across calls or write a different value, it'd have to do read memory to be able to determine when to do something different right? e.g. a global counter to write a different on multiple invocations.
>>>> So could we prove that it does the exact same thing across multiple back-to-back invocations given the same argument? Or could we consider this intrinsic to not really read to memory but still not produce the same results upon back-to-back invocations with the same argument?
>>>
>>> "write a constant to a constant location" is only true if you have no arguments. Basically, constants + arguments is what you have to decide what and where to write. Same arguments + write only => same effect.
>>>
>>> [EDIT] On second though. We might have intrinsics that make this more complicated as they allow you to get input without reading things. I'm not 100% sure but the "read thread ID" intrinsics on GPUs might fall into that category.
>>
>> Basically can we optimize
>>
>>   %b = @llvm.writeonly(%a)
>>   %c = @llvm.writeonly(%a)
>>
>> to just
>>
>>   %b = @llvm.writeonly(%a)
>>
>> and RAUW `%c` with `%b`
>
> I'd argue that we can't without further information -- the write may be volatile.

If that is the case, then it seems that writeonly is useless (and probably should be specified that it can't do volatile writes).
For example, readonly says:
"A readonly function always returns the same value (or unwinds an exception identically) when called with the same set of arguments and global state. "
One could argue that readonly function could do volatile load, and thus can't be CSEd.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109548/new/

https://reviews.llvm.org/D109548