similar to: Heap Exhaustion during 'DAGCombiner::Run'

Martin: I suspect this is an issue with post-DAG legalization store merging in the DAGCombiner. If you have a custom lowered type the DAGCombiner may end up merging a set of stores and immediately splitting them up in legalization. You should be able to disable this pass universally by overriding mergeStoresAfterLegalization() or conditionally for cases that shouldn't match with

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,

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

Explicitly re-adding a node to be processed doesn't work, because the processing order is canonical. 2017-05-22 11:39 GMT-07:00 Nirav Davé <niravd at google.com>: > You can always explicitly add D to the worklist when you make the > transformation with AddToWorklist. Presuambly this was the cause for your > infinite loop. > > -Nirav > > > On Mon, May 22, 2017 at

The root problem is that, when A gets modified, D doesn't get added back to the worklist. I could match the pattern on A, but the problem remains: when D gets modified, A do not get added back tot he worklist. I also considered ding several round of DAGCombine, but it is very easy to run into infinite loops, even with a fair amount of sanity checks. 2017-05-22 7:30 GMT-07:00 Nirav Davé

Hi LLVM-Devs, When I try to configure LLVM v6.0 RC2 (SVN Rev #324869) on Windows (I haven't yet had a chance to try on Linux), I get a series of errors such as this: CMake Error at cmake/modules/AddLLVM.cmake:1333 (add_dependencies): The dependency target "(" of target "check-all" does not exist. Call Stack (most recent call first): CMakeLists.txt:937

Maybe it's caused by the space after the X86 argument? Can you try removing all the -D flags, and see if that works? Then add them one by one to see which is the culprit? -Dimitry > On 17 Feb 2018, at 23:11, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi LLVM-Devs, > > When I try to configure LLVM v6.0 RC2 (SVN Rev #324869) on Windows

Hi, I'm working with workload where the bottleneck is cryptographic signature checks. Or, in compiler terms, most large integer operations. Looking at rL296252 , the state of affair in that area degraded quite significantly, see test/CodeGen/X86/i256-add.ll for instance. Is there some kind of work in progress here and it is expected to get better ? Because if not, that's a big problem.

I'm trying to optimize a pattern that goes roughly as: A / \ B C \ / D Problem is, when A gets modified, B and C get added back to the worklist, but D doesn't. Readding D to the worklist just create an infinite loop where one process D again and again. Is there a proper way to make this work ? -------------- next part -------------- An HTML attachment was scrubbed...

Hi Serge, Thanks for your help. I have looked at the change log, and so far as I can tell, my implementation is pretty much identical to all of the in-tree targets, but I’m missing something and can’t see what it is. I have simplified my TD description to just: def MyCallseqStart : SDNode<"ISD::CALLSEQ_START", SDCallSeqStart<[SDTCisVT<0, i32>,

Since updating to the LLVM v5.0 Final tag, I am seeing a crash when I enable '-g'. With a Debug build this hits an assertion at line #923 in 'lib/CodeGen/AsmPrinter/DwarfDebug.cpp': assert(EndLabel && "Forgot label after instruction ending a range!"); The values of related variables at this time are: 'Begin' is: DBG_VALUE %I23, %noreg,

Yes, it looks like passing ‘EnableVec’ and ‘EnableSLPVec’ to ‘Args.hasFlag’ should be replaced with ‘false’ and then it has the expected behaviour. MartinO From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Martin J. O'Riordan via cfe-dev Sent: 01 March 2018 18:02 To: 'Richard Smith' <richard at metafoo.co.uk> Cc: 'Clang Dev'

Hi LLVM-Devs, I have managed to complete updating our sources from LLVM v4.0 to v5.0, but I am getting selection errors for 'callseq_end'. I am aware that the 'ADJCALLSTACKUP' and 'ADJCALLSTACKDOWN' patterns have changed, and have added an additional argument to the TD descriptions for these. There are interactions with 'ISD::CALL' and 'ISD::RET_FLAG',

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 Mon, 18 Jun 2007, Chris Lattner wrote: > On Thu, 14 Jun 2007, Dietmar Ebner wrote: >> currently, the DAGCombiner unconditionally converts >> (DAGCombiner::visit(U|S)REM) expressions of the form X % C for constants >> C into X-X/C*C. this makes sense in certain cases where the div/mul >> logic will simplify X/C*X but is counterproductive in general, >>

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

Hi Martin, On 25 September 2017 at 20:35, Martin J. O'Riordan <MartinO at theheart.ie> wrote: > Are you building a Debug or Release version of the compiler? It seems that in Release builds of LLVM 5.0 the dump() implementation is absent, although the method is available in the interface. This is plain wrong in my view. If the dump() has to be removed then it should not be present

I got bit by this in LLVM 2.4 DagCombiner.cpp and it's still in trunk: SDValue DAGCombiner::visitSTORE(SDNode *N) { [...] // If this is a store of a bit convert, store the input value if the // resultant store does not need a higher alignment than the original. if (Value.getOpcode() == ISD::BIT_CONVERT && !ST->isTruncatingStore() && ST->isUnindexed()) {

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, currently, the DAGCombiner unconditionally converts (DAGCombiner::visit(U|S)REM) expressions of the form X % C for constants C into X-X/C*C. this makes sense in certain cases where the div/mul logic will simplify X/C*X but is counterproductive in general, especially if the multiply is expensive. also, this doesn't allow targets to custom lower rem operations. shouldn't this