search for: valuetypes

Hi guys, When I am trying to define pattern in a multi class, I got something like this: “ multi class P_PAT<string sty, SDNode tNode> { def : Pat<( !cast<ValueType>(“v2” # sty) (tNode !cast<ValueType>(“v2” # sty):$src1, !cast<ValueType>(“v2” # sty):$src2) ), ( add !cast<ValueType>(“v2” # sty):$src1, !cast<ValueType>(“v2” #

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

...te that all registers in a register class must have the same // ValueType. list<ValueType> RegTypes = regTypes; The comment seems out of date -- it says that only one type is allowed, while list is used. Can somebody explain what would it mean for a register class to have several allowed ValueTypes? Thanks, Volodya

After doing a bunch of work for moving pre-legalize extended ValueTypes into a table in SelectionDAG, I may have just found a simpler approach. There are under 32 simple ValueType values, so we only really need 5 bits to represent those. ValueType is already a 32-bit type on most hosts; what if we make use of the remaining 27 bits instead of using an external table?...

I would like to apply the attached patch which changes MVT::ValueType (currently a uint32_t) into a one-element struct (the element being a uint32_t). This makes it harder to misuse MVT::ValueType. Thanks to this patch I found two cases in which the arguments to DAG.getConstant were inverted and one in which getStore was being passed an ValueType for the "volatile" argument. When I

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

...o something else and make MVT::ValueType a plain integer type. Values beyond the range of the original enum are interpreted as indices into a UniqueVector which holds pairs of vector lengths and element types. This would require most of the ValueType utility routines to be aware of the new kinds of ValueTypes so that they could handle them properly, but once that's done, it would allow vector nodes to be handled consistently between pre-legalize and post-legalize, without obscure constructs like ... blahblah->getNumOperands()-2 ... ... *(blahblah->op_end()-1) ... to get the vector length a...

...). Does ValueType have something to do with that? In the same file, the VR64 register class has the following definition: def VR64 : RegisterClass<"X86", [v8i8, v4i16, v2i32, v1i64], 64, [MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7]>; So there are multiple ValueTypes here (the scalar registers each only have one corresponding to the bit size of the register). But still, if I have physical register MM2, that completely determines its register class. Is there some other architecture where the physical register name/number does not completely determine its regi...

On Jun 22, 2007, at 11:06 AM, Dan Gohman wrote: > After doing a bunch of work for moving pre-legalize extended > ValueTypes > into a table in SelectionDAG, I may have just found a simpler > approach. > > There are under 32 simple ValueType values, so we only really need > 5 bits > to represent those. ValueType is already a 32-bit type on most > hosts; what > if we make use of the remaining...

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

I was running into a problem with compiling llvm with gcc 4.4 on fedora 11 with --enable-optimized. I was seeing this warning dozens of times: /net/hakodate/scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h: In member function ‘llvm::SDNode*<unnamed>::SPUDAGToDAGISel::Select(llvm::SDValue)’: /net/hakodate/scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h:362: warning: comparison always false due to limited range of data type And on "make check" would print out: llc: /scratch/llvm...

...ve the same > // ValueType. > list<ValueType> RegTypes = regTypes; > > The comment seems out of date -- it says that only one type is allowed, > while list is used. Thanks, fixed! > Can somebody explain what would it mean for a register > class to have several allowed ValueTypes? This is useful for targets where multiple types of the same size can be held in the same registers. For example, if the target has a unified register file for Int/FP, it could have [i64, f64]. In practice, this is most useful for vector types, the X86 backend has [v16i8, v8i16, v4i32, v2i64...

On Aug 18, 2009, at 11:50 AM, Erick Tryzelaar wrote: > I was running into a problem with compiling llvm with gcc 4.4 on > fedora 11 with --enable-optimized. I was seeing this warning dozens of > times: > > /net/hakodate/scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h: In > member function > ‘llvm::SDNode*<unnamed>::SPUDAGToDAGISel::Select(llvm::SDValue)’: > /net/hakodate/scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h:362: > warning: comparison always false due to limited range of data type > > And on "make check" would p...

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

...are in the build log as well. > > Thanks, > > I ran into the same problem and fixed it by forcing the MVT::SimpleValueType enum to be 64 bits so that all of the types in the union later in the class are the same size. I tested this on ppc64 and x86_64. Index: include/llvm/CodeGen/ValueTypes.h =================================================================== --- include/llvm/CodeGen/ValueTypes.h (revision 66504) +++ include/llvm/CodeGen/ValueTypes.h (working copy) @@ -21,6 +21,8 @@ #include "llvm/Support/DataTypes.h" #include "llvm/Support/MathExtras.h" +stat...

How do I get the TargetRegisterClass for a physical register? SSARegMap::getRegClass only works for virtual registers. -Dave

Take a look at getPhysicalRegisterRegClass( const MRegisterInfo *MRI, MVT::ValueType VT, unsigned reg) in ScheduleDAG.cpp. -- Christopher Lamb On Jun 18, 2007, at 4:52 PM, David A. Greene wrote: > How do I get the TargetRegisterClass for a physical register? > SSARegMap::getRegClass only works for virtual registers. > >

Index: llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp =================================================================== --- llvm.orig/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp 2007-07-14 16:59:23.000000000 +0200 +++ llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp 2007-07-14 16:59:52.000000000 +0200 @@ -696,7 +696,7 @@ } } break; - case ISD::EH_RETURN: + case ISD::EH_RETURN: {

Hi Manuel, Here's another commit authored through the web interface where no discussion or reviewership information is apparent on the mailing list. All we see in cases like this are a few unthreaded list posts by the original author followed by an SVN revision number: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140714/226166.html For any patch that's submitted for

llvm[3]: Compiling SPUISelDAGToDAG.cpp for Debug build In file included from /Volumes/mrs5/net/llvm/llvm/lib/Target/CellSPU/ SPUISelDAGToDAG.cpp:334: /Volumes/mrs5/net/llvm/llvm-build/lib/Target/CellSPU/ SPUGenDAGISel.inc: In member function ‘llvm::SDNode* SPUDAGToDAGISel::Emit_5(const llvm::SDOperand&, unsigned int, unsigned int, llvm::MVT::ValueType, llvm::MVT::ValueType)’: