This is an archive of the discontinued LLVM Phabricator instance.

AMDGPU: Restore atomic fp feature on FP atomic instruction definitions
ClosedPublic

Authored by arsenm on Apr 9 2021, 3:46 PM.

Details

Reviewers
rampitec
Summary

9931b1f7a4785b6a17fb87b81a3546d61d0cbca1 switched this to checking for
the two specific subtargets, instead of the dedicated feature. This
broke supporting functions which force added the feature when emitting
targets that do not actually support them. This stil does not work for
the targets that use the gfx6/7 or gfx10 encodings.

Diff Detail

Event Timeline

arsenm created this revision.Apr 9 2021, 3:46 PM
arsenm requested review of this revision.Apr 9 2021, 3:46 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 9 2021, 3:46 PM
Herald added a subscriber: wdng. · View Herald Transcript
rampitec requested changes to this revision.Apr 9 2021, 3:54 PM

We should not produce this for gfx803.

This revision now requires changes to proceed.Apr 9 2021, 3:54 PM
arsenm added a comment.Apr 9 2021, 3:56 PM

We should not produce this for gfx803.

We need to produce something. The expectation is the function should be dynamically dead.

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.

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

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.

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

rampitec accepted this revision.Apr 22 2021, 1:49 PM

OK, I guess it is non-functional anyway.

This revision is now accepted and ready to land.Apr 22 2021, 1:49 PM