similar to: [LLVMdev] 3 element vector type

On Feb 12, 2007, at 1:41 AM, Christopher Lamb wrote: > > selector refused to select certain ops (specifically stores) for some > instructions when the operand type wasn't the first type for the > register class. After some digging around I seem to have solved the > problem by creating bitconvert patterns between the types in the > register class like the following: > >

On Feb 12, 2007, at 12:58 PM, Evan Cheng wrote: > > On Feb 12, 2007, at 1:41 AM, Christopher Lamb wrote: > >> >> selector refused to select certain ops (specifically stores) for some >> instructions when the operand type wasn't the first type for the >> register class. After some digging around I seem to have solved the >> problem by creating bitconvert

Hi All, I'm working on a back end for an architecture that makes use of multi- typed register classes. def MR: RegisterClass<"namespace", [type1, type2, ... ], ... > When running some preliminary tests I found that the instruction selector refused to select certain ops (specifically stores) for some instructions when the operand type wasn't the first type for the

> > Thanks Evan, > > I had tried something like this, but ran into some problems. > > llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:1478: failed assertion > `MVT::isVector(VT) && "Cannot promote this load!"' > > and > > llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:1766: failed assertion > `MVT::isVector(VT) && "Unknown legal

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

Hello, Im back trying to finish my backend to a simple RISC cpu SABRE now that most of the tedious process of examining undergraduate students is out of the way. I have managed to describe the registers and the instructions in the architecture and have added support for 32 bit immediates (thanks to Christopher Lamb) as the instruction set only supports 17 bit immediates directly. Could

On Feb 13, 2007, at 11:27 AM, Evan Cheng wrote: >> >> Thanks Evan, >> >> I had tried something like this, but ran into some problems. >> >> llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:1478: failed assertion >> `MVT::isVector(VT) && "Cannot promote this load!"' >> >> and >> >>

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 Tue, Mar 15, 2016 at 2:21 PM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 3/15/2016 4:16 PM, Rail Shafigulin via llvm-dev wrote: > >> Below is the output of llc with a -debug-only=isel. As you could see the >> output type for load, store, and add changes from v4i32 to i32 during >> legalization. How can I preserve the output type to

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

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 Sat, 17 Feb 2007, Nicolas Geoffray wrote: > Alright, thx Evan, that's what I did. > > Here are the final patches I think can be committed. I tried to separate > them into independent chunks, but I'm not sure how to do this in a good > way because of CVS and since everything is kind of related. Sorry for the delay, I applied the patches after some cleanups. Please

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

Hi Chris, Chris Lattner wrote: > Sorry for the delay, > > No problem. Plus the reviewing may have taken some time. So thx a lot for committing. I talked to Jim who said he wanted to commit his changes before mine -- I hope everything's Ok. > I applied the patches after some cleanups. Please keep code within 80 > columns, please don't use nested ?: expressions without

On Apr 23, 2007, at 1:17 PM, Christopher Lamb wrote: > > On Apr 23, 2007, at 12:31 PM, Chris Lattner wrote: > >> On Mon, 23 Apr 2007, Christopher Lamb wrote: >>> How can one let the back end know how to insert and extract >>> elements of >>> a vector through sub-register copies? I'm at a loss how to do >>> this... >> >> You

No, that is correct. I am adding the new types so that I can bitcast v2i8 into a v1i16 and then perform the 'and' operation and have legalize types turn the v1i16 into a scalar. Though I am having trouble in understanding how x86 supports the <1 x i64> type. Based on looking at the code, it should fail because v1i64 is not supported on the x86 platform as far as I can tell. Micah

On Apr 23, 2007, at 12:31 PM, Chris Lattner wrote: > On Mon, 23 Apr 2007, Christopher Lamb wrote: >> How can one let the back end know how to insert and extract >> elements of >> a vector through sub-register copies? I'm at a loss how to do this... > > You probably want to custom lower the insertelement/extractelement > operations for the cases you support.

Hi, I would like to restart the conversation regarding adding SVE support to LLVM. This time I am framing things from the code generation point of view because our immediate priority is llvm-mc support rather than auto-vectorisation. Can you please review the following text outlining MVT changes we would like to make so SVE instructions can be added to the AArch64 Target. My overriding

Hrmm.... PromoteVectorOp doesn't seem to follow this at all. http://llvm.org/svn/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp SDValue VectorLegalizer::PromoteVectorOp(SDValue Op) { // Vector "promotion" is basically just bitcasting and doing the operation // in a different type. For example, x86 promotes ISD::AND on v2i32 to // v1i64. EVT VT =

>Though I am having trouble in understanding how  x86 supports the <1 x i64> type. Based on looking at the code, it should fail because v1i64 is not supported on the x86 platform as >far as I can tell. The Type-Legalizer can handle vector types in the following ways: 1. Split - this splits vectors into two halves. For example on SSE4, <4 x i64> is split to <2 x i64> 2.