This is an archive of the discontinued LLVM Phabricator instance.

[AMDGPU] Add TII::isIgnorableUse() to allow VOP rematerialization
ClosedPublic

Authored by rampitec on Jul 12 2021, 12:34 PM.

Details

Summary

Any def of EXEC prevents rematerialization of any VOP instruction
because of the physreg use. Create a callback to check if the
physreg use can be ingored to allow rematerialization.

Diff Detail

Event Timeline

rampitec created this revision.Jul 12 2021, 12:34 PM
rampitec requested review of this revision.Jul 12 2021, 12:34 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 12 2021, 12:34 PM
Herald added a subscriber: wdng. · View Herald Transcript

Commit message should say TII

llvm/lib/Target/AMDGPU/SIInstrInfo.cpp
127

This also needs to verify it's a VALU use, you could still have an implicit exec read of a scalar instruction

rampitec retitled this revision from [AMDGPU] Add TTI::isAmbientPhysRegUse() to allow VOP rematerilization to [AMDGPU] Add TII::isAmbientPhysRegUse() to allow VOP rematerilization.Jul 12 2021, 12:38 PM
rampitec updated this revision to Diff 358061.Jul 12 2021, 1:59 PM
rampitec marked an inline comment as done.

Check instruction is VALU.

PSDB and ePSDB passed.

foad added a comment.Jul 13 2021, 6:12 AM

Typo in summary "rematerialization".

llvm/lib/CodeGen/LiveRangeEdit.cpp
116–117

Update this comment?

llvm/lib/Target/AMDGPU/SIInstrInfo.cpp
126

Typo "And".

rampitec updated this revision to Diff 358300.Jul 13 2021, 9:23 AM
rampitec marked 2 inline comments as done.
rampitec retitled this revision from [AMDGPU] Add TII::isAmbientPhysRegUse() to allow VOP rematerilization to [AMDGPU] Add TII::isAmbientPhysRegUse() to allow VOP rematerialization.

Updated comments.

The definition of "ambient" is so vague that I have no idea what it's trying to convey.

There is already a concept of "pristine" registers, which sounds similar. How is this different?

The definition of "ambient" is so vague that I have no idea what it's trying to convey.

There is already a concept of "pristine" registers, which sounds similar. How is this different?

It is not the same as pristine registers. For pristine registers the idea is that value in a register must be preserved but actually unused in a function. In this case value is not preserved and actually may be used, it is just not directly used in an instruction. The EXEC register holds "execution mask", essentially a mask of active threads. We add it as an implicit operand to all VALU instructions to model the dependency on this mask. However, these instructions do not really read EXEC, it is just a predicate. This implicit use is more or less an "environment" thing.

I agree that "ambient" sounds vague and would appreciate any suggestion.

I think it would be a lot better to add the concept of a "rematerializable" physical register. I think that currently physical registers are considered volatile, unless they are constant, but there was some talk a while back about refining the classification to allow exactly this sort of thing.

I think it would be a lot better to add the concept of a "rematerializable" physical register. I think that currently physical registers are considered volatile, unless they are constant, but there was some talk a while back about refining the classification to allow exactly this sort of thing.

There was such idea, but it unfortunately not applicable here. SALU instructions and even some VALU instructions can use EXEC as a data operand. That is only a special implicit use on a VALU instruction is a non-data use to be ignored.

Maybe rename it to isRematerializableUse()? At least it will be a specific name.

Yes, that's what I meant. I.e. not "it this register always rematerializable", but "it this register rematerializable in this situation".

It will require more work, because we may need to insert instructions that restore the value of that physical register, and currently that's not happening.

Yes, that's what I meant. I.e. not "it this register always rematerializable", but "it this register rematerializable in this situation".

It will require more work, because we may need to insert instructions that restore the value of that physical register, and currently that's not happening.

We specifically do not want anything trying to manage the value of the register here. It's a predicate register and we want the value to be whatever it happens to be at that point. If the predicate was on for a lane at the def, it's fine if that bit is off at the use. The inverse would be an invalid situation to begin with

We specifically do not want anything trying to manage the value of the register here. It's a predicate register and we want the value to be whatever it happens to be at that point. If the predicate was on for a lane at the def, it's fine if that bit is off at the use. The inverse would be an invalid situation to begin with

So you don't care if exec has a different value at OldIdx and UseIdx?

We specifically do not want anything trying to manage the value of the register here. It's a predicate register and we want the value to be whatever it happens to be at that point. If the predicate was on for a lane at the def, it's fine if that bit is off at the use. The inverse would be an invalid situation to begin with

So you don't care if exec has a different value at OldIdx and UseIdx?

Yes. It's a bitmask of active lanes. It's safe to rematerialize the instruction for lanes which are active at the def, but only a subset are at the use which would look like a different register value

Then either implement "isRematerializableUse", and add support for rematerializing it that does nothing for your target, or change it to something like "isIgnorableUse".

What I'm trying to accomplish is to make it applicable to other targets as well, so I'm trying to classify it as a special case of an issue that can occur elsewhere.

rampitec updated this revision to Diff 358707.Jul 14 2021, 12:54 PM
rampitec retitled this revision from [AMDGPU] Add TII::isAmbientPhysRegUse() to allow VOP rematerialization to [AMDGPU] Add TII::isIgnorableUse() to allow VOP rematerialization.
rampitec edited the summary of this revision. (Show Details)

Renamed callback to isIgnorableUse().

kparzysz accepted this revision.Jul 14 2021, 12:56 PM
This revision is now accepted and ready to land.Jul 14 2021, 12:56 PM
This revision was landed with ongoing or failed builds.Jul 14 2021, 1:04 PM
This revision was automatically updated to reflect the committed changes.