[llvm-dev] Relationship between MachineMemOperand and X86II::getMemoryOperandNo

Mircea Trofin via llvm-dev llvm-dev at lists.llvm.org
Fri Mar 9 08:19:15 PST 2018


Thanks for the details!

How should we think of the case where an instruction has memory operands
(in the sense that X86II::getMemoryOperandNo >=0), but doesn't have
MachineMemOperands?

I'm seeing an example in the case of __builtin_prefetch (lowered via
SelectionDAG::getMemIntrinsicNode, which produces a MachineMemOperand) vs
__builtin_ia32_gatherpfdpd, lowered through getPrefetchNode in
X86ISelLowering.cpp. The latter doesn't have a MachineMemOperand.

Is the latter technically a bug, maybe, and it so happens nothing is
hindered by the absence of the MachineMemOperand, so we're not observing it?

Added Elena, based on commit log in X86ISelLowering.cpp, perhaps she has
more context.

Thanks!
Mircea


On Thu, Mar 8, 2018 at 2:09 PM Francis Visoiu Mistrih <francisvm at yahoo.com>
wrote:

> Hello Mircea,
>
> > On 8 Mar 2018, at 18:52, Mircea Trofin via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > Hello,
> >
> > I'm trying to understand the relationship between MachineMemOperand and,
> on X86, memory operands of machine instructions. The latter seem to be
> operands held in order by the MachineInstr, from an offset onwards - Base,
> Scale, Index, Displacement, Segment. The former, if I understand it
> correctly, is used to hold a relationship back to IR load/store
> instructions.
>
> MachineMemOperands are used to represent memory references, so that the
> (generic) code generator can reason about their dependencies and aliases.
>
> You can see them when:
> * you call MachineInstr::dump (llc -print-after-all, etc.), at the end of
> the instruction, there is a "; mem:LD4..."
> * using MIR (llc -stop-before/-run-pass/etc.), at the end of the
> instruction, ":: (load 4…)”
> * using llc -asm-verbose, they are emitted as comments "# 4-byte Reload”
>
> MachineInstrs will have multiple operands, ex:
>
> > %5 = MOV64rm %0, 1, $noreg, 0, $noreg
>
>
> and in order to know which operand is what, the X86 backend uses some
> enums and helper functions so that they can write code like:
>
> > const MachineOperand &BaseReg  = MI->getOperand(Op+X86::AddrBaseReg);
>
> > const MCOperand &BaseReg  = MI.getOperand(Op+X86::AddrBaseReg);
>
> for both MachineInstrs and MCInsts.
>
> >
> > Is it possible to have a X86 MachineInstr with a memory operand (i.e.
> X86II::getMemoryOperandNo >=0), that has no MachineMemOperand? What about
> the reverse?
> >
>
> * Attaching a MachineMemOperand to an instruction that doesn’t reference
> any memory:
>
> From what I tried, the instruction has to be marked as “mayLoad /
> mayStore” (you can see them in X86InstrInfo.td) in order to pass the
> verifier:
>
> > $rbx = MOV64rr $rax :: (load 4)
>
> > bb.0:
> >   liveins: $rax
> >   $rbx = MOV64rr $rax; mem:LD4[<unknown>]
> >
> > # End machine code for function foo.
> >
> > *** Bad machine code: Missing mayLoad flag ***
> > - function:    foo
> > - basic block: %bb.0  (0x7fc884017678)
> > - instruction: $rbx = MOV64rr $rax; mem:LD4[<unknown>]
> >
> > LLVM ERROR: Found 1 machine code errors.
>
> * Memory-touching MachineInstrs without MachineMemOperands:
>
> > $rbx = MOV64rm _, 1, _, 0, _
>
>
> This is allowed.
>
> (anyone, please correct me if I’m wrong on anything here)
>
> Cheers,
>
>> Francis
>
> > Thanks,
> > Mircea.
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180309/81f02b35/attachment.html>


More information about the llvm-dev mailing list