[PATCH] D100236: AMDGPU: Restore atomic fp feature on FP atomic instruction definitions

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Apr 22 13:11:13 PDT 2021


arsenm added a comment.

In D100236#2709759 <https://reviews.llvm.org/D100236#2709759>, @rampitec wrote:

> In D100236#2706898 <https://reviews.llvm.org/D100236#2706898>, @arsenm wrote:
>
>> In D100236#2680845 <https://reviews.llvm.org/D100236#2680845>, @rampitec wrote:
>>
>>> In D100236#2680838 <https://reviews.llvm.org/D100236#2680838>, @arsenm wrote:
>>>
>>>> In D100236#2680833 <https://reviews.llvm.org/D100236#2680833>, @rampitec wrote:
>>>>
>>>>> We should not produce this for gfx803.
>>>>
>>>> We need to produce something. The expectation is the function should be dynamically dead.
>>>
>>> The feature itself is not sufficient, you cannot just expand atomicrmw into this without knowledge of other target properties. Unfortunately these has changed since first defined.
>>
>> What other target properties? This is supposed to be the target property to say the instruction is available
>
> All that interactions with ret/noret flavors and flushing. I am not sure how could you produce this instruction for an unrelated HW. I would say atomicrmw shall be expanded into a CAS loop in this case, at least it will work.

The point is there is no hardware. This is driven purely by the feature, not the specific device. This is the only feature required to handle this case (plus the mode settings for unsafe/flush).


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

https://reviews.llvm.org/D100236



More information about the llvm-commits mailing list