search for: machinememoperands

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 particular, a MachineMemOperand has a Value associated with it for the original LLVM IR pointer, but is there any guarantee that this will be valid for *all* memory-...

...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 optimization/codegen passes for maintaining the contents of a MachineMemOperand? In particular, a MachineMemOperand has a Value associated with it for the original LLVM IR pointer, but is there any guarantee that this will be valid for *...

...ustin 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 optimization/codegen > passes for maintaining the contents of a MachineMemOperand? In particular, > a MachineMemOperand has a Value associated with it for the original LLVM IR > pointer, but is there any guarantee that th...

...n. > > It sounds like you're looking for a property of an instruction, not an > operand. If you're looking for vector instructions, that should be > captured in TargetInstrInfo, not in MachineInstrs/Operands. Yes, I've written all that support. But that doesn't cover MachineMemOperands. AFAIK there's no machine-independent way to tell which instruction operands make up a MachineMemOperand. And even then, that would only tell you about the compoenents that make up the address, not the data itself. Note that having a machine-independent way to associate MachineOperands with...

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

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. Is it possible to have

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

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

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

...like you're looking for a property of an instruction, not an >> operand. If you're looking for vector instructions, that should be >> captured in TargetInstrInfo, not in MachineInstrs/Operands. > > Yes, I've written all that support. But that doesn't cover > MachineMemOperands. AFAIK there's no machine-independent way to tell which > instruction operands make up a MachineMemOperand. And even then, that would > only tell you about the compoenents that make up the address, not the data > itself. Note that having a machine-independent way to associate >...

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; mem:LD4[%u...

...i <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, optional information that late optimizers may use to combine or reorder memory operations. In particular, stripping all MMOs does not break the semantics of the program, it just removes some opportunities for optimization. A load or store without an MMO should be treat...

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

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

...> We've discussed the mechanisms before but I wanted to run the > > patch by everyone before I start to commit pieces. > > The Offset->FrameIndex mapping seems rather heavy-weight, as > any expense is incurred even when AsmVerbose is off. Would it > be possible to use MachineMemOperands instead? In theory, > they should already be preserving the needed information. If > they're not sufficient, could they be improved? Yeah, I'm not totally happy with that mapping either. With MachineMemOperands, would that be the getOffset() method? That's only for FPRel data...

Would anyone object if I add a field for the ValueType of a MachineMemOperand? Since it's not always known, by default I'd set it to "Other." But sometimes it is know when the MachineMemOperand is created and it would be useful to have that information. -Dave

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

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

...MIB.addReg(OffReg); MIB.addImm(Offset).addImm(Pred).addReg(PredReg); ++NumLDRDFormed; On Tue, Sep 7, 2010 at 1:31 PM, Bill Wendling <wendling at apple.com> wrote: > 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...

Hi! Does anyone know how it should be interpreted when one MI has multiple MachineMemOperands? (I've tried to find information but could not find any clear definition.) For example BranchFolder may do things like this (also see https://godbolt.org/z/iphFH4): # *** IR Dump Before Control Flow Optimizer ***: bb.0.entry: ... JCC_1 %bb.2, 5, implicit killed $eflags JMP_1 %bb.1 bb.1...