search for: dagcombining

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

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

Duncan: DAGCombine is inserting an IllegalOperation after target-specific instruction legalization has occurred. I'm inserting the fabs and the bitconvert during instruction legalization; DAGCombine is converting the fabs/bitconvert to an 'and' on its second (third?) pass. -scooter On Jan 20, 2009, at 12:24 AM, Duncan Sands wrote: > On Tuesday 20 January 2009 07:52:37

Yes, it was I who put that rant in the commit log and it's justified. Worse, it's unreasonable to actually go through all of DAGCombiner's code and check to see if certain kinds of constants, e.g., i64, are legal during a particular phase of DAGCombiner. DAGCombiner does good work and the backends are supposed to be good citizens. CellSPU is certainly trying to be a good citizen, no

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

Hi all, The DAGCombiner pass actually runs even if the optimize level is set to None. This can result in incorrect debug information or unexpected stepping/debugging experience. Not to mention that having good stepping/debugging experience is the major reason to compile at /O0. I recently suggested a patch to disable one specific DAG combine at /O0 that broke stepping on a particular case

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

Hi Scott, I'm not clear on what you're saying here; some of your points below seem to be contradictory. The advice to use target-independent nodes when feasible seems sound to me, so I wrote up a comment about it in SelectionDAGNodes.h. If you can formulate your thoughts in the form of specific documentation changes, that would be helpful. In theory, DAGCombiner is supposed to check if

Hi All, I'm writing a backend for a target which only supports 4-byte, 4-byte-aligned loads and stores. I custom-lower all {*EXT}LOAD and STORE nodes in TargetISelLowering.cpp to take advantage of all alignment information available to the backend, rather than treat each load and store conservatively, which takes O(10) instructions. My target's allowsUnalignedMemoryOperations()

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

new warnings, I think lib/CodeGen/SelectionDAG/DAGCombiner.cpp: In member function ‘llvm::SDValue<unnamed>::DAGCombiner::FindBetterChain(llvm::SDNode*, llvm::SDValue)’: lib/CodeGen/SelectionDAG/DAGCombiner.cpp:6006: warning: ‘SrcValueOffset’ may be used uninitialized in this function lib/CodeGen/SelectionDAG/DAGCombiner.cpp:6006: note: ‘SrcValueOffset’ was declared here

We discovered what is happening. SDAGCombiner essentially looks at various combinations of nodes to do with vectors, and when it can, it creates a vector shuffle. The problem is, that our vector shuffle lowering builds new trees with vector element, or vector sub-vector insert sequences. The generic DAGCombiner, reconstructs these into a new shuffle, and so the loop continues - we reduce it,

Hi Gabriele, > 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

> Historically nodes marked "custom" were considered legal, so the > DAGCombiner would have been correct to generate it. Not sure how > that ever worked though. I think Dan split the isOperationLegal > method into isOperationLegal and isOperationLegalOrCustom for reasons > related to this kind of thing. I don't know whether the DAGCombiner > is now only supposed

On Tuesday 20 January 2009 07:52:37 Evan Cheng wrote: > Right. DAGCombine will insert *illegal* nodes before legalize. There are two stages of legalization: legalization of types, followed by legalization of operations. Before type legalization DAGCombine is allowed to create nodes with illegal types and illegal operations. After type legalization but before operation legalization it is

Martin: It sounds like you are doing is more akin to shuffle selection than fusion and therefore it's a better fit for instruction selection than DAGCombining. Try movign it to <Target>ISelDAGToDAG's Select (or potentially PreprocessISelDAG). Th -Nirav On Tue, Mar 6, 2018 at 4:05 PM Martin J. O'Riordan <MartinO at theheart.ie> wrote: > We discovered what is happening. > > > > SDAGCombiner essentially looks at var...

Hi Gabrielle, > > Historically nodes marked "custom" were considered legal, so the > > DAGCombiner would have been correct to generate it. Not sure how > > that ever worked though. I think Dan split the isOperationLegal > > method into isOperationLegal and isOperationLegalOrCustom for reasons > > related to this kind of thing. I don't know whether

On Jul 1, 2013, at 11:52 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Mon, Jul 1, 2013 at 11:30 AM, Quentin Colombet <qcolombet at apple.com> wrote: > Hi, > > ** Problematic ** > I am looking for advices to share some logic between DAG combine and target lowering. > > Basically, I need to know if a bitcast that is about to be inserted during target

Is this piece of code in DAGCombiner::visitLOAD removing a dead node? 06155 if (N->use_empty()) { 06156 removeFromWorkList(N); 06157 DAG.DeleteNode(N); 06158 } If it is, is there a reason it doesn't push its operands to the work list as done in line 974-975? 00970 // If N has no uses, it is dead. Make sure to revisit all N's operands once

On Wednesday 18 February 2009 21:43, Dan Gohman wrote: > I agree, that doesn't look right. It looks like this > is what was intended: > > Index: lib/CodeGen/SelectionDAG/DAGCombiner.cpp > =================================================================== > --- lib/CodeGen/SelectionDAG/DAGCombiner.cpp (revision 65000) > +++ lib/CodeGen/SelectionDAG/DAGCombiner.cpp