similar to: Relationship between MachineMemOperand and X86II::getMemoryOperandNo

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,

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

On Sep 7, 2010, at 10:48 AM, Akira Hatanaka wrote: > I have two questions regarding MachineMemOperands and dependence information. > > Q1) I noticed that MachineMemOperands are lost when two LDRs are combined and a LDRD is generated in ARMPreAllocLoadStoreOpt:::RescheduleOps. > > (before optimization) > %reg1033<def> = LDR %reg1030, %reg0, 4100, pred:14, pred:%reg0;

I have two questions regarding MachineMemOperands and dependence information. Q1) I noticed that MachineMemOperands are lost when two LDRs are combined and a LDRD is generated in ARMPreAllocLoadStoreOpt:::RescheduleOps. (before optimization) %reg1033<def> = LDR %reg1030, %reg0, 4100, pred:14, pred:%reg0; mem:LD4[%uglygep10] %reg1054<def> = LDR %reg1030, %reg0, 4104, pred:14,

Sorry, this is the part in ARMLoadStoreOptimizer.cpp that creates a LDRD instruction. Ops.pop_back(); Ops.pop_back(); // Form the pair instruction. if (isLd) { MachineInstrBuilder MIB = BuildMI(*MBB, InsertPos, dl, TII->get(NewOpc)) .addReg(EvenReg, RegState::Define)

I want to get some clarification on the exact semantics of the MachineMemOperand attached to memory-touching instructions. From what I understand, a MemSDNode has an associated MachineMemOperand and a MachineInstr can have zero or more attached MachineMemOperands. But what is the guarantee/constraint placed on optimization/codegen passes for maintaining the contents of a MachineMemOperand? In

On 11 Dec 2012, at 21:00, Justin Holewinski wrote: > I want to get some clarification on the exact semantics of the MachineMemOperand attached to memory-touching instructions. From what I understand, a MemSDNode has an associated MachineMemOperand and a MachineInstr can have zero or more attached MachineMemOperands. > > But what is the guarantee/constraint placed on

The code itself makes sense, but I want to know if this breaks any guarantee made about preserving a Value* in the MachineMemOperand. It sounds like we're having the same issue. We were using the Value* stored in the MachineMemOperand to get address space information during assembly printing. The alternative is carrying around a lot of extra (redundant) information in the SDAG. If it is

On Dec 11, 2012, at 11:00 AM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > I want to get some clarification on the exact semantics of the MachineMemOperand attached to memory-touching instructions. From what I understand, a MemSDNode has an associated MachineMemOperand and a MachineInstr can have zero or more attached MachineMemOperands. The MMOs provide extra,

Thanks for your advice. But I have searched X86 and find no more information than I have known. The problem is not to create a MachineMemOperand, but to create a MachineMemOperand with certain address. This scene does not exist in the original code. Since I have to do this in the process of register allocating, inserting IR instruction seems to be infeasible. I have thought of storing the address

On Tuesday 01 December 2009 15:04, Chris Lattner wrote: > > The size is actually calculated from an EVT nearly everywhere (and > > where it's not it should be easy to add). We could just replace the > > size with the EVT and have more information. > > It sounds like you're looking for a property of an instruction, not an > operand. If you're looking for

Is there a reason MachineMemOperands are not guaranteed to be persisted in late optimization passes? Is there a use-case where they should be stripped? On Wed, Dec 12, 2012 at 9:50 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Dec 12, 2012, at 5:50 PM, Justin Holewinski < > justin.holewinski at gmail.com> wrote: > > > Is this documented somewhere?

On Tuesday 01 December 2009 12:14, Dan Gohman wrote: > On Dec 1, 2009, at 9:03 AM, David Greene wrote: > > On Tuesday 01 December 2009 11:01, Chris Lattner wrote: > >> What are you trying to accomplish? What would use this? > > > > I am trying to determine whether a MachineMemOperand is a vector > > operand. > > Again, what's that for? If you're

On Dec 1, 2009, at 1:10 PM, David Greene wrote: > On Tuesday 01 December 2009 15:04, Chris Lattner wrote: > >>> The size is actually calculated from an EVT nearly everywhere (and >>> where it's not it should be easy to add). We could just replace the >>> size with the EVT and have more information. >> >> It sounds like you're looking for a

On Dec 1, 2009, at 11:43 AM, David Greene wrote: > On Tuesday 01 December 2009 12:14, Dan Gohman wrote: >> On Dec 1, 2009, at 9:03 AM, David Greene wrote: >>> On Tuesday 01 December 2009 11:01, Chris Lattner wrote: >>>> What are you trying to accomplish? What would use this? >>> >>> I am trying to determine whether a MachineMemOperand is a vector

Is this documented somewhere? On Wed, Dec 12, 2012 at 6:54 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Dec 11, 2012, at 11:00 AM, Justin Holewinski < > justin.holewinski at gmail.com> wrote: > > > I want to get some clarification on the exact semantics of the > MachineMemOperand attached to memory-touching instructions. From what I >

On Dec 13, 2012, at 4:43 AM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > Is there a reason MachineMemOperands are not guaranteed to be persisted in late optimization passes? Is there a use-case where they should be stripped? That's not really the issue, though. As an intermediate representation, MI should be reasonably self-contained. The MMOs are pointers into an

Hi all, I met a new problem in the process of my project. I have got an address by mmap. And I want to build a MachineInstr of MOV64mr to move a value to the address. But it seems that the MachinePointerInfo needs a pointer to a Value. So can I create a MachineMemOperand directly with the address (is a long*) ? Or I need to try some other methods? Thanks a lot, Will -------------- next part

Usually I will search the target directory, X86 in your case, to see how MOV64mr is used with BuildMI to generate the instruction I want. 2018-04-16 16:25 GMT+08:00 Will Lester via llvm-dev <llvm-dev at lists.llvm.org>: > Hi all, > I met a new problem in the process of my project. > I have got an address by mmap. And I want to build a MachineInstr of MOV64mr > to move a value to

On Dec 12, 2012, at 5:50 PM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > Is this documented somewhere? It seems that it isn't. It ought to go in the header file. /jakob