Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
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. |
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.
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. |
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. |