similar to: [LLVMdev] Rework of Vector/Scalar Classification

On Dec 4, 2009, at 2:44 PM, David Greene wrote: > Here's a reworked patch to mark instructions and operands as vector > or scalar. > It uses TableGen to infer the flags from types, allowing the user to > override > with a "let isVector = 0" clause. > > I decided to forego classifying MachineMemOperands for now in the > interests of > getting this

On Friday 04 December 2009 16:44, David Greene wrote: > Here's a reworked patch to mark instructions and operands as vector or > scalar. It uses TableGen to infer the flags from types, allowing the user > to override with a "let isVector = 0" clause. > > I decided to forego classifying MachineMemOperands for now in the interests > of getting this piece in. I still

On Tuesday 08 December 2009 13:23, Chris Lattner wrote: > Your diff isn't clean and won't apply to mainline, you have some > previously committed changes, like the extraneous #include of > MachineMemOperand.h. Yes, I know. I was simply asking for a review. I can regenerate it if you wish. > More significantly, as I mentioned before, I don't think this is a > great

On Dec 8, 2009, at 12:08 PM, David Greene wrote: > On Tuesday 08 December 2009 13:23, Chris Lattner wrote: > >> Your diff isn't clean and won't apply to mainline, you have some >> previously committed changes, like the extraneous #include of >> MachineMemOperand.h. > > Yes, I know. I was simply asking for a review. I can regenerate it > if you wish.

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

On Tuesday 08 December 2009 16:01, Dan Gohman wrote: > > I don't see how a register MachineOperand is obviously a vector unless > > there's type information somewhere that I'm missing. > > It has a register which has a register class. It's true that LLVM > currently uses one register class for both scalar and vector uses > of XMM registers on x86, but you

On Dec 9, 2009, at 8:20 AM, David Greene wrote: > On Tuesday 08 December 2009 16:01, Dan Gohman wrote: > >>> I don't see how a register MachineOperand is obviously a vector unless >>> there's type information somewhere that I'm missing. >> >> It has a register which has a register class. It's true that LLVM >> currently uses one register

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

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

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

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,

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

On Monday 14 September 2009 12:22, Dan Gohman wrote: > Hi Dave, > > On Sep 11, 2009, at 3:31 PM, David Greene wrote: > > Attached is a patch to print asm comments for spill information. > > 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

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

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

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,

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,

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;