[PATCH] D152798: [AMDGPU][ValueTracking] Handle amdgcn intrinsics that cannot create poison

Tue Jun 13 05:50:17 PDT 2023

nikic added a reviewer: nlopes.
nikic added a subscriber: nlopes.
nikic added a comment.

In D152798#4417179 <https://reviews.llvm.org/D152798#4417179>, @foad wrote:

>>> I was wondering about that case myself. I don't see the benefit of saying that a load-like intrinsic can return poison, unless the compiler recognizes it as a load well enough to do things like forwarding a previously stored value through it.
>>
>> Not sure I follow. Do you want to define your load intrinsics are performing an implicit freeze? You could do that, but I'm not sure it is desirable.
>
> I don't understand the big picture here: what possible benefit is there to telling the compiler that the value that is loaded can (or can't) be poison, when the compiler knows nothing else about the provenance of that value?
>
> (By contrast, for a //normal// IR load, I can see that tracking the poison-ness of the loaded value might be useful, so that IR passes can add or remove store->load pairs without affecting poison-ness.)

Okay, I think I get what you mean now. You want to say the load result is non-poison/undef, because the compiler will never replace the load with a literal undef/poison value due to lack of optimization support, and as such you can't introduce practical miscompiles with it. This makes me pretty uncomfortable, because you'd effectively be lying, just in a way that shouldn't matter. Maybe @nlopes has some insight on whether this could cause any specific issues.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152798