[PATCH] D37397: AMDGPU: Handle more than one memory operand in SIMemoryLegalizer

[Tony Tye via Phabricator via llvm-commits]

t-tye added a comment.

In https://reviews.llvm.org/D37397#859430, @arsenm wrote:

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


https://reviews.llvm.org/D37397