search for: extract_element

...et to do the expansion: ExpandADDSUB(SDNode *N, SelectionDAG &DAG) { assert(N->getValueType(0) == MVT::i64 && (N->getOpcode() == ISD::ADD || N->getOpcode() == ISD::SUB) && "Unknown operand to lower!"); // Extract components SDOperand LHSL = DAG.getNode(ISD::EXTRACT_ELEMENT, MVT::i32, N->getOperand(0), DAG.getConstant(0, MVT::i32)); SDOperand LHSH = DAG.getNode(ISD::EXTRACT_ELEMENT, MVT::i32, N->getOperand(0), DAG.getConstant(1, MVT::i32)); SDOperand RHSL = DAG.getNode(ISD::EXTRACT_ELEMENT, MVT::i32, N->getOperand(1), DAG.getConstant(0, MVT::i32)); SDOpera...

My target doesn't support 64 bit arithmetic, so I'd like to supply definitions for adde/addc. The problem is I can't seem to figure out the magic. Here's an example of what I need to generate: # two i64s in r5/r6 and r7/r8 # result in r1/r2, carry in r3 # adde add r2, r6, r8 cmpltu r3, r2, r6 # compute carry # addc add r1, r5, r7 add r1, zero, r3 Is this

...not unlike the ManagedStatic objects in VMCore/Type.cpp, for example. 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 out whole legal vectors at a time instead of just individual elements, for example. While my original patch made the extended ValueType table explicitly hold vector element types and vector lengths, I had converted it to hold Type*, and ran into problems because VectorType doesn't permi...

...g to reorder your email a bit to suit my evil purposes: > 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 > out whole legal vectors at a time instead of just individual elements, for > example. Hrm, now that you mention it, I do remember that. I'd file that into a category of "evil hacks", not something that we really want to support. To me, I think it would be much bett...

Hi Steve, Thanks for confirming that EXTRACT_ELEMENT is something I can use. I had seen it in the generated DAGs but was unsure whether I was "allowed" to use it, if that's the right word. I checked up on it more and indeed the mainstream targets like ARM use that node type in custom lowering code, so that should solve that. Perhaps in...

I forgot to mention that I used EXTRACT_ELEMENT in my backend to get the high and low parts of an SDValue. On 10 Nov 2013, at 17:50, Steve Montgomery <stephen.montgomery3 at btinternet.com> wrote: > I had a similar problem with a backend for the 68HC12 family which also has no barrel shifter. Some 68HC12 CPUs support shift for just on...

...ass you gave has some subregs, you can give load/store a custom legalisation where you change the i64 to MVT::Untyped. So something like this for ISD::STORE: SDValue ValueToBeStored = St.getOperand(…) auto SeqOps[] = { DAG.getTargetConstant(SP::IntPairRegClassID, MVT::i32), DAG.getNode(ISD::EXTRACT_ELEMENT, dl, MVT::i32, ValueToBeStored, DAG.getConstant(0, MVT::i32)), DAG.getTargetConstant(SP ::sub0, MVT::i32), DAG.getNode(ISD::EXTRACT_ELEMENT, dl, MVT::i32, ValueToBeStored, DAG.getConstant(1, MVT::i32)), DAG.getTargetConstant(SP ::sub1, MVT::i32) }; SDValue NewValueToBeStored = DAG.getMachine...

...examining the DAG before you lower the ISD::CALL node? > Right before the call to LowerOperation for the ISD::CALL node the DAG looks like this: SelectionDAG has 23 nodes: 0x97a3c78: ch = EntryToken 0x97a43e0: <multiple use> 0x97a41a0: <multiple use> 0x97a3cd8: i32 = extract_element 0x97a43e0, 0x97a41a0 0x97a3d30: ch = ArgFlags < zext orig-align:8 > 0x97a3d68: ch = ArgFlags < zext orig-align:1 > 0x97a3c78: <multiple use> 0x97a41a0: <multiple use> 0x97a41a0: <multiple use> 0x97a41a0: <multiple use> 0x97a4168: i32 = Ext...

Hello everyone, I wanted to attach a node without affecting the present nodes in any way. I tried to use MVT::Glue for that but I think I'm missing something as I could not achieve the below state. LUI LUI | | ADDI ----GLUE---- ADDI | store I've few question about this and Glue node in general, I'll be happy to get some help on

All the sub methods called inside ExpandIntegerOperand like ExpandInOp_STORE etc have access to the expanded operands map. Why they aren't passed to target LowerOperation? A target may also want to use the already expanded Lo and Hi parts. - Sanjiv -------------- next part -------------- An HTML attachment was scrubbed... URL:

...nside ExpandIntegerOperand like ExpandInOp_STORE > etc have access to the expanded operands map. > > Why they aren't passed to target LowerOperation? A target may also want to > use the already expanded Lo and Hi parts. You don't really need access to the map; just use build an EXTRACT_ELEMENT node, and legalize will take care of the mapping for you. -Eli

Currently I can use a BUILD_PAIR to make a pair of two arbitrary values to a desired result value. For example, I can make i8,build_pair = (i8, i8) or i16,build_pair = (i1, i8). This is turning out to very handy when I replace nodes during the expansion/legalization of types for my target. I was just wondering if we could go one more step further and create a BUILD_TRIPLET node which can

...instructions. At the pointer of custom > lowering register allocation has not yet been done, so I don't have > a way to communicate the dependency. > An example is in order: If I have a register v4r0 with subregisters {r0, r1, r2, r3} and a DAG that looks like load v4si <- extract_element 2 <- add -> load i32 I'd like to be able to generate load v4r0 load r10 add r11, r10, r2 <== subregister 2 of v4r0 -- Christopher Lamb

On Jul 1, 2008, at 3:42 PM, Richard Osborne wrote: > Evan Cheng wrote: >> On Jun 25, 2008, at 5:13 AM, Richard Osborne wrote: >> >> >>> Evan Cheng wrote: >>> >>>> On Jun 23, 2008, at 5:35 AM, Richard Osborne wrote: >>>> >>>> >>>>> I'm trying to write a backend for a target with no hardware

...> What does -debug-only=loop-vectorize say about it? FWIW, I agree, this sounds like a cost-model problem. The loop-vectorizer should be able to vectorize the 'icmp; neg; select' pattern, and then the backend can pattern-patch that with the reduction (which is a series of shuffles and extract_element) into the single instruction PSADBW -- we're quite likely missing the target code to do that. -Hal > > cheers, > --renato > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://l...

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.

...ction, so it can be wrapped by a subclass. * Implement LowerCallTo() in PPCTargetLowering to wrap TargetLowering::LowerCallTo() and legalize the return node when targeting SPE. * Augment PPCTargetLowering::LowerCall_32SVR4() to legalize MVT::f64 arguments that have been pre-processed into EXTRACT_ELEMENT(i64 BITCAST f64, 0/1) The purpose of this being to legalize intermediate illegal types post-type legalization. Is there a better approach? Comments from anyone else? - Justin On Wed, 2 Jan 2019 11:39:59 -0500 Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > It sounds like the l...

Evan Cheng wrote: > On Jun 25, 2008, at 5:13 AM, Richard Osborne wrote: > > >> Evan Cheng wrote: >> >>> On Jun 23, 2008, at 5:35 AM, Richard Osborne wrote: >>> >>> >>>> I'm trying to write a backend for a target with no hardware floating >>>> point support. I've added a single i32 register class. I'm

...re a custom legalisation where you change the i64 to MVT::Untyped. So something like this for ISD::STORE: >> >> SDValue ValueToBeStored = St.getOperand(…) >> >> auto SeqOps[] = { >> DAG.getTargetConstant(SP::IntPairRegClassID, MVT::i32), >> DAG.getNode(ISD::EXTRACT_ELEMENT, dl, MVT::i32, ValueToBeStored, DAG.getConstant(0, MVT::i32)), >> DAG.getTargetConstant(SP ::sub0, MVT::i32), >> DAG.getNode(ISD::EXTRACT_ELEMENT, dl, MVT::i32, ValueToBeStored, DAG.getConstant(1, MVT::i32)), >> DAG.getTargetConstant(SP ::sub1, MVT::i32) >> }; >> &...

...custom lowering register allocation has not yet been done, so I >> don't have a way to communicate the dependency. >> > > An example is in order: > > If I have a register v4r0 with subregisters {r0, r1, r2, r3} and a > DAG that looks like > > load v4si <- extract_element 2 <- add -> load i32 > > I'd like to be able to generate > > load v4r0 > load r10 > add r11, r10, r2 <== subregister 2 of v4r0 I see that Evan has added getSubRegisters()/getSuperRegisters() to MRegisterInfo. This is what's needed in order to implement the re...