similar to: [LLVMdev] Probably FAQ: can you insert BRCONDs during TargetLowering::LowerOperation?

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

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

Background: The Cell SPU does not have condition registers in the normal sense. It fits the "zero or negative one" model, preferably with an i32 register, which is what getSetCCResultType() will return. Problem: LegalizeTypes promotes i1 to i8 via an i32 setcc, i.e., the generated type legalization is: (i8:truncate (i32:setcc i32:lhs, i32:rhs, ch:cond)) How do I keep

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

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

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 some places, e.g. in

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

> On Jan 23, 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()

There are LLVM 2.9 RC1 pre-release tarballs source available. You can find them here: http://llvm.org/pre-releases/2.9/ Please download them, build them, and compile things to your heart's content. And most importantly file a bunch of bug reports. :-) Share and enjoy! -bw

I just ran across something interesting: DAGCombine inserts a 64-bit constant as the result of converting a (bitconvert (fabs val)) to a (and (bitconvert val), i64const). The problem: i64 constants have to be legalized for the CellSPU platform. DAGCombine is doing the right thing but it's not doing the right thing for CellSPU and it's damed difficult to work around this

After a hiatus on the CellSPU development, I've got all of the instructions necessary to get the llvm-gcc frontend to build. I've now discovered a new and interesting problem that I'm not sure how to solve cleanly and it's due to the fact that CellSPU has no fixed size condition flags. CellSPU's condition flags depend on the size of what's being compared, i.e., if both

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

On Fri, Dec 12, 2008 at 11:42 AM, Scott Michel <scottm at aero.org> wrote: > The alternative is to do fairly deep inspection of brconds to eliminate the > truncate, which eventually gets expanded into: > (i8:sext_in_reg (i8:truncate (i32:setcc ...))) Have you tried implementing computeMaskedBitsForTargetNode for your setcc nodes? If you have, I think DAGCombiner should take care

Right. DAGCombine will insert *illegal* nodes before legalize. Evan On Jan 19, 2009, at 8:17 PM, Eli Friedman wrote: > On Mon, Jan 19, 2009 at 6:36 PM, Scott Michel <scottm at aero.org> wrote: >> I just ran across something interesting: DAGCombine inserts a 64-bit >> constant as the result of converting a (bitconvert (fabs val)) to a >> (and (bitconvert val),

On Mon, Jan 19, 2009 at 6:36 PM, Scott Michel <scottm at aero.org> wrote: > I just ran across something interesting: DAGCombine inserts a 64-bit > constant as the result of converting a (bitconvert (fabs val)) to a > (and (bitconvert val), i64const). > > The problem: i64 constants have to be legalized for the CellSPU > platform. DAGCombine is doing the right thing but

Hello, In the combine 2 step (after legalization), in the DAGCombiner::visitBIT_CONVERT() method, the DAG combiner is replacing an FABS followed by a BIT_CONVERT, to a BIT_CONVERT followed by an AND 0x7FFFFFFFFFFFFFFF. Everything is 64 bit. On my target, FABS and BIT_CONVERT are legal in 64 bit, but AND in not legal in 64 bit (is declared custom). So the dag combiner is introducing illegal (not

Evan: And after legalize too. DAGCombine gets run after legalization. :-) -scooter On Jan 19, 2009, at 10:52 PM, Evan Cheng wrote: > Right. DAGCombine will insert *illegal* nodes before legalize. > > Evan > > On Jan 19, 2009, at 8:17 PM, Eli Friedman wrote: > >> On Mon, Jan 19, 2009 at 6:36 PM, Scott Michel <scottm at aero.org> >> wrote: >>> I

What is the difference between these two functions? The header file for TargetLowering class says that LowerArguments must be implemented, but only the Sparc and IA64 backends implement them. X86, PowerPC and CellSPU implement LowerFORMAL_ARGUMENTS, but I can find a setOperationAction that states that they should be lowered. Can someone please explain this for me? Thanks, Micah Villmow