search for: loweroperation

Hi, I see that for different targets in classes which inherits from TargetLowering there are implemented both methods: LowerOperation and ReplaceNodeResults What decides that for one given ISD we have to add handling in LowerOperation and for other in ReplaceNodeResults, when for both SetOperationAction is configured to be Custom? Is it related with number of results of given operation and LowerOperation is called when there...

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 gmail.com> napisał...

Hi, I'm a litle bit puzzled by the TargetLowering::LowerOperation function, and what different callers of this function assumes about the returned value. In several places it seems like it is assumed that LowerOperation can return three kinds of values: * Something completely new. * SDValue() * The same SDValue as LowerOperation was called on. However in som...

Hi, On 01/22/2016 05:02 PM, Tom Stellard wrote: > On Fri, Jan 22, 2016 at 01:58:49PM +0100, Mikael Holmén via llvm-dev wrote: >> Hi, >> >> I'm a litle bit puzzled by the TargetLowering::LowerOperation function, >> and what different callers of this function assumes about the returned >> value. >> > SelectionDAGLegalize::LegalizeOp() is your best reference for this. > >> In several places it seems like it is assumed that LowerOperation can >> return three kinds...

In LegalizeDAG.cpp, truncating stores are custom-lowered in line 1314-1317: 1314 case TargetLowering::Custom: 1315 ReplaceNode(SDValue(Node, 0), 1316 TLI.LowerOperation(SDValue(Node, 0), DAG)); 1317 break; Is there a reason it doesn't check whether the SDValue returned from TargetLowering::LowerOperation is null before it replaces the original node with the returned node? The return value is checked everywhere else TLI.LowerOperation is called (lin...

...gt; > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon- > 20081013/068667.html > > thanks, I remember now (more or less). So would something like > ReplaceNodeResults > solve the problem? > Well the magnitude of the task is not small. ExpandIntegerOperand() calls LowerOperation() to allow targets to handle illegal operands. So we will need to change the interface of LowerOperation() to pass an extra argument called Results, which is an array of SDValue. Targets will push the result values in this array and then we can replace values in ExpandIntegerOperand(). Very much li...

Hi Sanjiv, > Well the magnitude of the task is not small. > ExpandIntegerOperand() calls LowerOperation() to allow targets to handle > illegal operands. So we will need to change the interface of > LowerOperation() to pass an extra argument called Results, which is an > array of SDValue. Targets will push the result values in this array and > then we can replace values in ExpandIntegerOpe...

Hi Akira, On 01/06/12 02:27, Hatanaka, Akira wrote: > In LegalizeDAG.cpp, truncating stores are custom-lowered in line 1314-1317: > > 1314 case TargetLowering::Custom: > 1315 ReplaceNode(SDValue(Node, 0), > 1316 TLI.LowerOperation(SDValue(Node, 0), DAG)); > 1317 break; > > Is there a reason it doesn't check whether the SDValue returned from > TargetLowering::LowerOperation is null before it replaces the original node with > the returned node? The return value is checked everywhere else > TLI.L...

Hi Eli, I would like to clarify generally what the difference is between returning SDValue() and Op (input argument unchanged) from LowerOperation()? My understanding is that returning SDValue() means that Target gives up, and the common code is supposed to handle it. Returning Op, the unchanged argument, means that the Target is happy with the node as it is, and the common code can move on to something else. Are there any exceptions to...

...2017, at 12:36, Friedman, Eli via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 1/23/2017 5:21 AM, Jonas Paulsson wrote: >> Hi Eli, >> >> I would like to clarify generally what the difference is between returning SDValue() and Op (input argument unchanged) from LowerOperation()? >> >> My understanding is that returning SDValue() means that Target gives up, and the common code is supposed to handle it. Returning Op, the unchanged argument, means that the Target is happy with the node as it is, and the common code can move on to something else. > > Thi...

On Fri, 2009-01-16 at 10:03 +0100, Duncan Sands wrote: > Hi Sanjiv, > > > Well the magnitude of the task is not small. > > ExpandIntegerOperand() calls LowerOperation() to allow targets to handle > > illegal operands. So we will need to change the interface of > > LowerOperation() to pass an extra argument called Results, which is an > > array of SDValue. Targets will push the result values in this array and > > then we can replace values...

...e >>>> >>>> define double @div(double %a, double %b) { >>>> %result = fdiv double %a, %b >>>> ret double %result >>>> } >>>> >>>> is expanded to a ISD::CALL of __divdf3 which is then lowered via the >>>> LowerOperation hook of my backend. >>>> >>>> However I run into problems with fcmp. With the following code: >>>> >>>> define i1 @fmp(double %a) { >>>> %result = fcmp uno double %a, 0.000000e+00 >>>> ret i1 %result >>>> } >>...

On Jan 6, 2009, at 11:37 PM, Scott Michel wrote: > Chris: > > I was trying to avoid using the custom instruction emitter method. > Not as if I didn't look before I asked the question to see if there > was an easier way. Then no, there is no other way. -Chris

Chris: It occurred to me this morning that maybe the general solution to this particular type of problem is a custom/target-dependent DAG inserter pass, analogous to target lowering and DAG legalization. I'm not sure if this pass happens before or after legalization. Worth considering? I suppose the best way to discuss this is to just write the code. However, some preliminary

On Jan 6, 2009, at 5:53 PM, Scott Michel wrote: > It's yet another CellSPU thing: integer division is a long code > sequence we have to insert that has branches within it (test for 0 > divisor, etc.) Can't really emit the sequence of instructions via > tblgen (can't have labels or BBs). The other alternative is a custom > instruction emitter. > > Life could be

Chris: I was trying to avoid using the custom instruction emitter method. Not as if I didn't look before I asked the question to see if there was an easier way. -scooter On Tue, Jan 6, 2009 at 10:07 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jan 6, 2009, at 5:53 PM, Scott Michel wrote: > > > It's yet another CellSPU thing: integer division is a long

...>> the most part LLVM seems to get this right. For example >> >> define double @div(double %a, double %b) { >> %result = fdiv double %a, %b >> ret double %result >> } >> >> is expanded to a ISD::CALL of __divdf3 which is then lowered via the >> LowerOperation hook of my backend. >> >> However I run into problems with fcmp. With the following code: >> >> define i1 @fmp(double %a) { >> %result = fcmp uno double %a, 0.000000e+00 >> ret i1 %result >> } >> >> the fcmp is expanded to the a call to __unordd...

...ng all floating point operations to be lowered to library function calls. For the most part LLVM seems to get this right. For example define double @div(double %a, double %b) { %result = fdiv double %a, %b ret double %result } is expanded to a ISD::CALL of __divdf3 which is then lowered via the LowerOperation hook of my backend. However I run into problems with fcmp. With the following code: define i1 @fmp(double %a) { %result = fcmp uno double %a, 0.000000e+00 ret i1 %result } the fcmp is expanded to the a call to __unorddf2 which is then lowered via the LowerOperation hook of my backend. However...

It's yet another CellSPU thing: integer division is a long code sequence we have to insert that has branches within it (test for 0 divisor, etc.) Can't really emit the sequence of instructions via tblgen (can't have labels or BBs). The other alternative is a custom instruction emitter. Life could be easier if I could insert BRCONDs and other branches from within

...ms to get this right. For example >>> >>> define double @div(double %a, double %b) { >>> %result = fdiv double %a, %b >>> ret double %result >>> } >>> >>> is expanded to a ISD::CALL of __divdf3 which is then lowered via the >>> LowerOperation hook of my backend. >>> >>> However I run into problems with fcmp. With the following code: >>> >>> define i1 @fmp(double %a) { >>> %result = fcmp uno double %a, 0.000000e+00 >>> ret i1 %result >>> } >>> >>> the fcmp i...