This is an archive of the discontinued LLVM Phabricator instance.

AMDGPU: Handle more than one memory operand in SIMemoryLegalizer
ClosedPublic

Authored by kzhuravl on Sep 1 2017, 1:10 PM.

Diff Detail

Repository
rL LLVM

Event Timeline

kzhuravl created this revision.Sep 1 2017, 1:10 PM
t-tye added inline comments.Sep 1 2017, 3:24 PM
lib/Target/AMDGPU/AMDGPUMachineModuleInfo.h
38 ↗(On Diff #113586)

Suggest more descriptive comment:

/// \returns \p SSID's position in the total ordering of sync scopes such that a wider scope has a higher value than a narrower scope.
51 ↗(On Diff #113586)

Would be better to `reportUnknownSynchScope(MI);` since this code would need to be updated if the target introduced another sync scope value.

lib/Target/AMDGPU/SIMemoryLegalizer.cpp
204 ↗(On Diff #113586)

Should there be a TODO saying that this logic does not check that if MMOs are present they cover the entire set of locations accessed by the memory instruction. If they only partially cover then would need to assume the conservative assumption of sequentially consistent system scope.

227–230 ↗(On Diff #113586)

This logic seems to belong in `constructFromMI` which claims to create a SIMemOpInfo from a machine instruction. So it ought to do that for any machine instruction, including those with no MMOs.

Same comment for other cases.

arsenm edited edge metadata.Sep 1 2017, 3:56 PM

Why does this need to handle multiple mem operands? The only instructions where that really makes sense are for ds_read2_b32/ds_write2_b32 which this doesn't need to do anything with

t-tye edited edge metadata.Sep 1 2017, 4:30 PM

Why does this need to handle multiple mem operands? The only instructions where that really makes sense are for ds_read2_b32/ds_write2_b32 which this doesn't need to do anything with

So what are the rules when MMO are allowed and will be preserved? For example, is it guaranteed that no memory operation that originates from an atomic LLVM ir instruction will be combined with another memory instruction resulting in multiple MMOs? Technically the memory model does allow this in some cases, but are be promising that it will never happen?

Would it be possible to require that every memory operation that was atomic has a MMO that was required to be preserved through all optimizations? The current defaulting of memory instructions without any MMO to be treated as atomic seems uncomfortable, and is fragile when multiple MMOs are present since no check is made if the MMOs cover the entire set of memory locations. Should memory instructions have a property to indicate if they are atomic, and then the MMO could provide additional information about what kind of atomic.

Since instructions can have multiple MMOs can it be required that if they do then they are required not to originate from atomic instructions?

It would he helpful to document the rules on when MMOs are allowed/required.

arsenm added a comment.Sep 1 2017, 4:34 PM

Why does this need to handle multiple mem operands? The only instructions where that really makes sense are for ds_read2_b32/ds_write2_b32 which this doesn't need to do anything with

So what are the rules when MMO are allowed and will be preserved? For example, is it guaranteed that no memory operation that originates from an atomic LLVM ir instruction will be combined with another memory instruction resulting in multiple MMOs? Technically the memory model does allow this in some cases, but are be promising that it will never happen?

Would it be possible to require that every memory operation that was atomic has a MMO that was required to be preserved through all optimizations? The current defaulting of memory instructions without any MMO to be treated as atomic seems uncomfortable, and is fragile when multiple MMOs are present since no check is made if the MMOs cover the entire set of memory locations. Should memory instructions have a property to indicate if they are atomic, and then the MMO could provide additional information about what kind of atomic.

Since instructions can have multiple MMOs can it be required that if they do then they are required not to originate from atomic instructions?

It would he helpful to document the rules on when MMOs are allowed/required.

Combining multiple MMOs that refer to the same location is probably just broken. We don't really have instructions that can access multiple addresses at the same time (except for the ds read2/write2 and I suppose the direct load to LDS buffer mode). It doesn't really make sense to merge atomic operations. I could imagine an architecture with an atomic load addressing modes in multiple operands though.

kzhuravl updated this revision to Diff 113918.Sep 5 2017, 2:45 PM
kzhuravl marked 4 inline comments as done.

Address review feedback.

lib/Target/AMDGPU/AMDGPUMachineModuleInfo.h
51 ↗(On Diff #113586)

Discussed a different approach offline.

lib/Target/AMDGPU/SIMemoryLegalizer.cpp
204 ↗(On Diff #113586)

Discussed offline: this should be in validator. I have put a comment.

227–230 ↗(On Diff #113586)

Discussed offline.

t-tye accepted this revision.Sep 5 2017, 5:40 PM

LGTM

Should there be an MIR test with multiple MMOs?

This revision is now accepted and ready to land.Sep 5 2017, 5:40 PM
kzhuravl updated this revision to Diff 114050.Sep 6 2017, 12:35 PM

Changes discussed offline:

  • ErrorOr -> Optional
  • Minor renaming
t-tye accepted this revision.Sep 6 2017, 4:41 PM

LGTM with one suggested name change.

lib/Target/AMDGPU/SIMemoryLegalizer.cpp
190 ↗(On Diff #114050)

Suggest renaming to constructFromMIWithMMO since it only can be used when the instruction has MMOs.

This revision was automatically updated to reflect the committed changes.
kzhuravl marked an inline comment as done.