llvm dev - Feb 2019 - GlobalISEL, and MachineMemOperands?

Looking through the X86 GlobalISEL code for selecting loads and stores, 
I'm not seeing the creation of the MachineMemOperands I'd expect to see 
and do see being generated by SelectionDAG.  Is this simply an 
oversight, or is there some aspect of the new design which pushes us 
away from MMOs?

Various parts of the machine instruction level optimization passes use 
the existence and contents of an MMO for optimization legality checks.  
As a simple example, we won't fold a load unless we can examine it's MMO
to ensure the access is not volatile.  At the moment, this would seem to 
mean that GlobalISEL generated code can't have load folding done by the 
PeepholeOptimizer.  Unless I'm missing something?  I'm very new to 
GlobalISEL.

Philip

> On Feb 1, 2019, at 7:35 PM, Philip Reames via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Looking through the X86 GlobalISEL code for selecting loads and stores,
I'm not seeing the creation of the MachineMemOperands I'd expect to see
and do see being generated by SelectionDAG.  Is this simply an oversight, or is
there some aspect of the new design which pushes us away from MMOs?
The MMO is created in IRTranslator::translateLoad. The verifier also enforces
that it’s there. Where are you seeing them not used?

-Matt

Hi Philip,

MMOs are still required in GlobalISel. Looking at
X86InstructionSelector::selectLoadStoreOp(), it seems that X86 is selecting
their load instructions using MachineInstr::setDesc(). This mutates the existing
instruction and keeps the existing MMOs that were on the original G_LOAD.
> On Feb 1, 2019, at 16:35, Philip Reames <listmail at
philipreames.com> wrote:
> 
> Looking through the X86 GlobalISEL code for selecting loads and stores,
I'm not seeing the creation of the MachineMemOperands I'd expect to see
and do see being generated by SelectionDAG.  Is this simply an oversight, or is
there some aspect of the new design which pushes us away from MMOs?
> 
> Various parts of the machine instruction level optimization passes use the
existence and contents of an MMO for optimization legality checks.  As a simple
example, we won't fold a load unless we can examine it's MMO to ensure
the access is not volatile.  At the moment, this would seem to mean that
GlobalISEL generated code can't have load folding done by the
PeepholeOptimizer.  Unless I'm missing something?  I'm very new to
GlobalISEL.
> 
> Philip
>

On 2/1/19 4:40 PM, Matt Arsenault wrote:
>
>> On Feb 1, 2019, at 7:35 PM, Philip Reames via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>
>> Looking through the X86 GlobalISEL code for selecting loads and stores,
I'm not seeing the creation of the MachineMemOperands I'd expect to see
and do see being generated by SelectionDAG.  Is this simply an oversight, or is
there some aspect of the new design which pushes us away from MMOs?
> The MMO is created in IRTranslator::translateLoad. The verifier also
enforces that it’s there. Where are you seeing them not used?
I'm guessing this comes down to user error.  I tried reproducing this 
again, and saw the MMO as expected.  I'm guessing I got confused by not 
seeing the handling in the X86 code due to the mutation approach, and 
then misreading the debug output or something.

Sorry for the noise, and thanks for the quick response.

Philip