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 > > MVT::ValueType of v4f32. > > The short answer is no. A op of a number of different VTs can map to > the same instruction.In general, that may be true, but for most instructions isn't it 1:1? What are some examples where it isn't 1:1? The vector processor needs to know how the data in the register is organized to compute the operation, after all. Thinking about MOVAPS / MOVAPD I suppose one could argue that it's perfectly legal to do a MOVAPD on a vector register that contains 8-bit data. It's just bits, after all, but there is a "preference" to what should be in the register for performance reasons. It's not good to mix-and-match MOVAPD and MOVAPS on the same data.> However, given a register class you can get to > the list of VTs that map to it. Take a look at TargetRegisterDesc.Tha'ts usually not enough. For example, in an SSE operand you want to know the type of data contained in it (32-bit [or less] or 64-bit) to generate optimal code. Just knowing that it's a 128-bit vector register that can hold 8-, 16-, 32- or 64-bit data is not enough. Getting this information into the TargetInstrInfo / TargetOperandInfo would take a fair amount of TableGen and .td file hacking, I would think. Right? -Dave
On Sep 3, 2008, at 1:14 PM, David Greene wrote:> 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 >>> MVT::ValueType of v4f32. >> >> The short answer is no. A op of a number of different VTs can map to >> the same instruction. > > In general, that may be true, but for most instructions isn't it > 1:1? What > are some examples where it isn't 1:1? The vector processor needs to > know how the data in the register is organized to compute the > operation, after > all. > > Thinking about MOVAPS / MOVAPD I suppose one could argue that it's > perfectly legal to do a MOVAPD on a vector register that contains 8- > bit data. > It's just bits, after all, but there is a "preference" to what > should be in > the register for performance reasons. It's not good to mix-and- > match MOVAPD > and MOVAPS on the same data.For the case of MOVAPS vs. MOVAPD vs. MOVDQU (assuming you have a micro-architecture where there's actually a difference), this can be achieved by having instruction selection select the right instructions. For example, find code like this in X86InstrSSE.td: def : Pat<(alignedloadv2i64 addr:$src), (MOVAPSrm addr:$src)>, Requires<[HasSSE2]>; def : Pat<(loadv2i64 addr:$src), (MOVUPSrm addr:$src)>, Requires<[HasSSE2]>; and change it to not select MOVAPS for that microarchitecture, for example. Dan
On Sep 3, 2008, at 1:14 PM, David Greene wrote:> 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 >>> MVT::ValueType of v4f32. >> >> The short answer is no. A op of a number of different VTs can map to >> the same instruction. > > In general, that may be true, but for most instructions isn't it > 1:1? What > are some examples where it isn't 1:1? The vector processor needs to > know how the data in the register is organized to compute the > operation, after > all.What about bitcast'ed values? Or i1 value zero-extended and stored in i8 register?> > > Thinking about MOVAPS / MOVAPD I suppose one could argue that it's > perfectly legal to do a MOVAPD on a vector register that contains 8- > bit data. > It's just bits, after all, but there is a "preference" to what > should be in > the register for performance reasons. It's not good to mix-and- > match MOVAPD > and MOVAPS on the same data.That's not really true in many cases. On x86, sometimes many opcodes do the same thing. We often use the shortest one. Domain crossing penalty doesn't really matter in newer x86 implementations. Besides that's just an optimization, it's not an correctness issue.> > >> However, given a register class you can get to >> the list of VTs that map to it. Take a look at TargetRegisterDesc. > > Tha'ts usually not enough. For example, in an SSE operand you want > to know > the type of data contained in it (32-bit [or less] or 64-bit) to > generate > optimal code. Just knowing that it's a 128-bit vector register that > can hold > 8-, 16-, 32- or 64-bit data is not enough.Another question to ask is... What are you trying to achieve? What crazy ideas do you have? Evan> > > Getting this information into the TargetInstrInfo / > TargetOperandInfo would > take a fair amount of TableGen and .td file hacking, I would think. > Right? > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Wednesday 03 September 2008 15:42, Dan Gohman wrote:> For the case of MOVAPS vs. MOVAPD vs. MOVDQU (assuming you have a > micro-architecture where there's actually a difference), this can be > achieved by having instruction selection select the right instructions. > For example, find code like this in X86InstrSSE.td: > > def : Pat<(alignedloadv2i64 addr:$src), > (MOVAPSrm addr:$src)>, Requires<[HasSSE2]>; > def : Pat<(loadv2i64 addr:$src), > (MOVUPSrm addr:$src)>, Requires<[HasSSE2]>; > > and change it to not select MOVAPS for that microarchitecture, for > example.Unfortunately that doesn't help when, for example, you need to generate spill code. :) -Dave