search for: build_pairs

...s 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 contain three incoming operands instead of just two. I know that I can do that with two build_pairs , but a build_triplet will make my code cleaner and easy to follow. - Sanjiv

Hi, I have a custom lowering operation on ISD::BITCAST for the PowerPC/SPE target, to convert 'f64 bitcast (i64 build_pair i32, i32)' into a 'f64 BUILD_SPE64 i32, i32' node, which can be seen at https://reviews.llvm.org/D54583. However, when building compiler-rt's lib/builtins/divdc3.c an assertion is triggered that BUILD_PAIR is not legal on line 24. There should be no

Hi Nemanja, I'm attaching a patch that builds on D54583 and implements what we discussed on IRC earlier today. Particularly: * Make LowerCallTo() a virtual function, 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

Aside from the fact that you're checking for i64 specifically instead of generally checking for illegal types, how much of this is really PPC specific? Would this be a reasonable enhancement to the SDAG logic in general? -Hal On 1/4/19 8:03 AM, Nemanja Ivanovic wrote: The changes seem fine to me. I don't think this is excessively intrusive and it accomplishes what is needed by targets

+ Eli Friedman as he often has very insightful comments regarding back end changes. On Fri, Jan 4, 2019 at 9:03 AM Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > The changes seem fine to me. I don't think this is excessively intrusive > and it accomplishes what is needed by targets whose call lowering can > introduce illegal types. > Adding Justin Bogner as the

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

Hi, In SelectionDAGISel::SelectAllBasicBlocks if (TM.Options.EnableFastISel) FastIS = TLI->createFastISel(*FuncInfo, LibInfo); followed by if (!FastIS) { LowerArguments(Fn); } else { The above implies that implementing FastIS is optional. In contrast to that, testing whether FastIS is actually been used is done by testing if TM.Options.EnableFastISel is set. For example

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Fabian Scheler > Sent: Wednesday, August 15, 2012 9:12 AM > To: LLVM Developers Mailing List > Subject: [LLVMdev] More Back-End Porting Troubles > > Hi LLVM-Folks, > > as mentioned in an earlier post >

Richard Pennington wrote: > 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 #

Hi LLVM-Folks, as mentioned in an earlier post (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-July/051677.html) I am currently working on a Back-End for the TriCore processor. Currently, I am struggling as LLVM could not select zext and load, for instance, so some of the testcases in test/CodeGen/Generic are not successfully compiled by my back-end. Furthermore, I am completely puzzled by the

Hi, first of all: thanks for your kind, very helpful and unbelievable fast response! >> as mentioned in an earlier post >> (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-July/051677.html) I >> am currently working on a Back-End for the TriCore processor. >> Currently, I am struggling as LLVM could not select zext and load, for >> instance, so some of the testcases

I'm looking at the Legalize code and in 2.5 the above function is: void DAGTypeLegalizer::ExpandFloatRes_FADD(SDNode *N, SDValue &Lo, SDValue &Hi) { SDValue Call = LibCallify(GetFPLibCall(N->getValueType(0), RTLIB::ADD_F32, RTLIB::ADD_F64,

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

Evan Cheng wrote: > 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:

> -----Original Message----- > From: Fabian Scheler [mailto:fabian.scheler at gmail.com] > Sent: Thursday, August 16, 2012 4:58 AM > To: LLVM Developers Mailing List; Villmow, Micah > Cc: Stellard, Thomas; cameron.mcinally at nyu.edu > Subject: Re: [LLVMdev] More Back-End Porting Troubles > > Hi, > > first of all: thanks for your kind, very helpful and unbelievable

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

Thank you Craig for explanation. Could be the same algorithm used for custom legalizing given node in LowerOperation and ReplaceNodeResults in case results and inputs of the node are illegal? Or actually such situation is impossible and for given node either LowerOperation or ReplaceNodeResults can be only called? Przemek wt., 28 sty 2020, 18:48 użytkownik Craig Topper <craig.topper at

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

Hi Evan, Thanks for the useful pointer. When trying to implement the example to my situation I ran into a strange issue that I don't know how to resolve. My target doesn't support 64-bit operations and so far all operations have been expanded using LLVM except for division and remainder. For division, LLVM only gives you the option of either calling an external library or custom lowering

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more