similar to: [LLVMdev] MachineMemOperands

What are you trying to accomplish? What would use this? -Chris On Dec 1, 2009, at 8:48 AM, David Greene <dag at cray.com> wrote: > 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

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

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 interested in which pipeline a load feeds, ye olde Vector vs. Scalar isn't sufficient

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

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

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

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

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,

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

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

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 think we should add type information to MachineMemOperands. Why throw away

On Monday 14 September 2009 13:07, Dan Gohman wrote: > MachineMemOperands for spill slots use FixedStack PseudoSourceValues > as their base. There's a unique FixedStack PseudoSourceValue for each > fixed frame object, so it's independent of whether frame pointer > elimination has been done, and it's independent of the actual frame > offsets. >From

Is there an easy way to get the MVT::ValueType of a MachineInstruction MachineOperand? For example, the register operand of an x86 MOVAPD should have an MVT::ValueType of v2f64. A MOVAPS register operand should have an MVT::ValueType of v4f32. So given a MachineInstruction and its MachineOperands is there some easy way to derive this information? I don't see anything in TargetInstrInfo

On Tuesday 02 September 2008 16:47, Evan Cheng wrote: > On Sep 2, 2008, at 10:42 AM, David Greene wrote: > > Is there an easy way to get the MVT::ValueType of a MachineInstruction > > MachineOperand? For example, the register operand of an x86 MOVAPD > > should > > have an MVT::ValueType of v2f64. A MOVAPS register operand should > > have an > >

On Feb 11, 2010, at 11:31 AM, David Greene wrote: > On Wednesday 10 February 2010 14:58:58 Dan Gohman wrote: >> On Feb 10, 2010, at 12:42 PM, David Greene wrote: >>> On Wednesday 10 February 2010 12:58:25 Chris Lattner wrote: >>>> I think that adding a bit to LoadSDNode and StoreSDNode would make >>>> sense. >>> >>> Ok. The consequence

On Sep 2, 2008, at 10:42 AM, David Greene wrote: > Is there an easy way to get the MVT::ValueType of a MachineInstruction > MachineOperand? For example, the register operand of an x86 MOVAPD > should > have an MVT::ValueType of v2f64. A MOVAPS register operand should > have an > MVT::ValueType of v4f32. The short answer is no. A op of a number of different VTs can map to

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