similar to: ConstantFP and Use

Hello all, I recently foudn myself wanting to view the basic blocks in the selection DAG as pure DAGs - so just as a list of edges, with no other information. I added the below code to the start of the " void SelectionDAGISel::CodeGenAndEmitDAG()" function. It creates a separate txt file for each basic block and gives a list of edges between nodes. The segment of code is below -

Hi, While profiling LLVM using my test-cases with huge MBBs, I noticed that FoldingSetNodeID operations (ComputeHash,insertion,etc) may become really inefficient for the nodes, which have very many operands. I can give you an example of what is meant by "very many". In my test-case (you can fetch it from here http://llvm.org/bugs/attachment.cgi?id=1275), which is just one HUGE MBB

Hi Chris, This is a good idea and I started thinking in that direction already. But what I don't quite understand the TFs, how TFs are formed and which rules they should obey to. For example now: > PendingLoads created by the SelectionDAGLowering::getLoadFrom and then copied into the > TokenFactor node by SelectionDAGLowering::getRoot called from the >

Hi Chris, Your were totally right with your suggestion. I have implemented the code that : a) does not merge multiple TokenFactor nodes in the DAGCombiner::visitTokenFactor(), if the resulting TF node would contain more than 64 operands. b) produces a bunch of TokenFactor nodes with at most 64 operands, instead of one huge TokenFactor in the SelectionDAGLowering::getRoot(). If we have n

I'm trying to implement *MUL_LOHI for my processor. My processor has mulxss (e.g.) that gives the 32 high bits of a 64 bit multiply. I tried this in ios2ISelDAGToDAG.cpp: /// Mul/Div with two results case ISD::SMUL_LOHI: case ISD::UMUL_LOHI: { SDValue Op1 = Node->getOperand(0); SDValue Op2 = Node->getOperand(1); AddToISelQueue(Op1);

Hi Akira, > 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 } yes. > 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,

I'm trying to write a tablegen pattern to that matches a sequence of SDNodes and emits again an SDNode and another instruction. The pattern I've written looks like the folowing: def : Pat<(foo (bar GPR:$rs1), simm12:$imm1), (bar (BAZ GPR:$rs1, simm12:$imm1))>; foo and bar are SDNodes, BAZ is an instruction. In particular, bar is defined as follows: def bar :

Hi Quentin, yes, this happens quite late. With the Option --debug-pass=Structure it's in or after "Assembly Printer". I do have a very simple DAGToDAGISel::Select() method: SDNode *MyTargetDAGToDAGISel::Select(SDNode *N) { SDLoc dl(N); // default implementation if (N -> isMachineOpcode()) { N -> setNodeId(-1); return NULL; // Already selected. } SDNode

Hi Quentin, I added some debug output (N->dump()) in ::Select(SDNode*N) and compared it to the dot/Graphviz output (-view-legalize-types-dags; the last one with correct code). I found out, that some SDNodes are not passed to the ::Select(SDNode*N), approximately 11 nodes are missing. The first add-node (v1+v2) is missing. Is it normal that not all nodes are passes to ::Select()? Thanks,

Hi Quentin, Am 01.11.2014 um 00:39 schrieb Quentin Colombet <qcolombet at apple.com>: > > On Oct 31, 2014, at 11:00 AM, Boris Boesler <baembel at gmx.de> wrote: > >> Hi Quentin, >> >> I added some debug output (N->dump()) in ::Select(SDNode*N) and compared it to the dot/Graphviz output (-view-legalize-types-dags; the last one with correct code). I

SelectionDAG's computeKnownBits has no case for ConstantFP, e.g. Known.ones = cast <ConstantFPSDNode>(Op)->getValueAFP ().bitcastToAPInt (); I can't easily override this in target specific code. Can anyone see an issue with submitting the patch to upstream? Suggestions for an in tree target that could trigger this would be very welcome. Cheers -------------- next part

That's very good. We're clearly further from head of dev than I realised! Thanks for the link. On 19 Jan 2018 18:53, "Friedman, Eli" <efriedma at codeaurora.org> wrote: On 1/19/2018 4:01 AM, Jon Chesterfield via llvm-dev wrote: > SelectionDAG's computeKnownBits has no case for ConstantFP, e.g. > Known.ones = cast <ConstantFPSDNode>(Op)->getValueAFP

Hi All, At some point in the next week or two I'm going to remove the ConstantFP::get(type, APFloat) method. Right now, you can immediately fix your code by dropping the first 'type' argument. For example, if you have: ConstantFP::get(Ty, APFloat(1.0)) just change it to: ConstantFP::get(APFloat(1.0)) Both forms work with SVN head right now so you can migrate as

I just ran into this today with x86-64: Cannot yet select: 0x3cbc180: f64 = ConstantFP <1> As far as I can tell, DAGCombiner comes along and sees an sint_to_fp of the constant 1 and hapilly folds it into a ConstantFP<1>. ISel then blows up because there's no pattern for it. Does this look familiar to anyone? I don't see any relevant bugs in the database.

On Sep 24, 2008, at 5:11 PM, David Greene wrote: > I just ran into this today with x86-64: > > Cannot yet select: 0x3cbc180: f64 = ConstantFP <1> > > As far as I can tell, DAGCombiner comes along and sees an sint_to_fp > of the > constant 1 and hapilly folds it into a ConstantFP<1>. ISel then > blows up > because there's no pattern for it. > >

On Thursday 25 September 2008 19:12, Chris Lattner wrote: > On Sep 24, 2008, at 5:11 PM, David Greene wrote: > > I just ran into this today with x86-64: > > > > Cannot yet select: 0x3cbc180: f64 = ConstantFP <1> > > > > As far as I can tell, DAGCombiner comes along and sees an sint_to_fp > > of the > > constant 1 and hapilly folds it into a

On Sep 26, 2008, at 8:43 AM, David Greene wrote: >> >> Do you have a testcase? It sounds like something that would be easy >> to fix. > > I have a fix (yes, it was trivial). I'll have to see about a > testcase as it's > proprietary code. Usually, proprietary testcases can be reduced and simplified to the point where they are innocuous, -Chris

On Friday 26 September 2008 16:59, Chris Lattner wrote: > On Sep 26, 2008, at 8:43 AM, David Greene wrote: > >> Do you have a testcase? It sounds like something that would be easy > >> to fix. > > > > I have a fix (yes, it was trivial). I'll have to see about a > > testcase as it's > > proprietary code. > > Usually, proprietary testcases

On Sep 29, 2008, at 9:21 AM, David Greene wrote: >> Usually, proprietary testcases can be reduced and simplified to the >> point where they are innocuous, > > Yep, that's what I'm trying to do. Have you run delta?

I get this message once in a while and llvm exits the program. What might be the cause ? llvm version: svn host: Linux x86_64 -- Regards, Gabi http://bugspy.net