similar to: [LLVMdev] a possible alternative for pre-legalize extended ValueTypes

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 >

Right now there are special SelectionDAG node kinds for operations on "abstract" vector types (VLOAD, VADD, and all the rest), and a special MVT::Vector ValueType for them. These nodes carry two additional operands, constants which specify the vector length and element type. All of this is only used before legalize; then they are replaced with regular node kinds and value types. It

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

Hello, Here's a quick update on where I'm at with the pre-legalize vector changes I'm working on. I hope to have an updated patch ready to a few days, assuming I don't get too busy with other projects going on. Here are some of the issues I've come across so far. Putting the table for extended ValueTypes in SelectionDAG seems quite involved. There are a lot of places that use

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 Mon, 11 Jun 2007, Dan Gohman wrote: > Here's a quick update on where I'm at with the pre-legalize vector changes > I'm working on. I hope to have an updated patch ready to a few days, assuming > I don't get too busy with other projects going on. Here are some of the issues > I've come across so far. Great! I'm going to reorder your email a bit to suit my

Hi, I'm porting some existing code of mine to CVS HEAD, and don't understand something about new RegisterClass TableGen definition: class RegisterClass<string namespace, list<ValueType> regTypes,........ { ..... string Namespace = namespace; What is this "namespace" thing? It looks like it should contain the name of backend, right? // RegType

On Monday 18 June 2007 19:02, Christopher Lamb wrote: > Take a look at getPhysicalRegisterRegClass( > const MRegisterInfo *MRI, > MVT::ValueType VT, > unsigned reg) > > in ScheduleDAG.cpp. Yuck. I was afraid of that. What is the ValueType needed for? Isn't the register id itself an indication of the ValueType it represents? Where I'm at I

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

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

On Sat, 13 May 2006, Vladimir Prus wrote: > I'm porting some existing code of mine to CVS HEAD, and don't understand > something about new RegisterClass TableGen definition: > > class RegisterClass<string namespace, list<ValueType> regTypes,........ > { > ..... > string Namespace = namespace; > > What is this "namespace"

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

Michel Salim wrote: > On Fri, Feb 6, 2009 at 8:42 PM, Tanya Lattner <tonic at nondot.org> wrote: >> LLVMers, >> >> The 2.5 pre-release is available for testing: >> http://llvm.org/prereleases/2.5/ >> > I'm updating the Fedora packaging of LLVM, and with the 02/20 > prerelease it fails to build on ppc64: > >

On Fri, Feb 6, 2009 at 8:42 PM, Tanya Lattner <tonic at nondot.org> wrote: > LLVMers, > > The 2.5 pre-release is available for testing: > http://llvm.org/prereleases/2.5/ > I'm updating the Fedora packaging of LLVM, and with the 02/20 prerelease it fails to build on ppc64: http://koji.fedoraproject.org/koji/taskinfo?taskID=1148023 make[1]: Entering directory

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

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

Ahead of the Wednesday’s roundtable at the developers’ conference, here is version three of the proposal for first-class complex types in LLVM. I was not able to add Krzysztof Parzyszek’s suggestion of a “cunzip” intrinsic returning two vectors as I could not find examples of intrinsics that return two values at the IR level. The Hexagon intrinsics declared to return two values do not actually

On Mon, Jun 11, 2007 at 03:39:40PM -0700, Chris Lattner wrote: > On Mon, 11 Jun 2007, Dan Gohman wrote: > > Also, CopyToReg and CopyFromReg lowering/legalization rely on being able to > > create vector-of-vector types. For example, an <8 x double> vector is bitcasted > > to (effectively) <4 x <2 x double>> for x86, allowing EXTRACT_ELEMENT to pull > >

Hey all, I volunteered to put together a proposal regard complex in LLVM. Consider the following to be a strawman meant to spark discussion. It's based on real-world experience with complex but is not expected to cover all use-cases. Proposal to Support Complex Operations in LLVM ---------------------------------------------- Abstract Several vendors and individuals have proposed