search for: sdagcombin

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 n...

...struction 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 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...

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

Hi LLVM-Devs, I am in the process of updating our out-of-tree implementation from v5.0 to v6.0 RC3, and while it builds and mostly runs, I am having trouble with a small number of tests where the 'WorklistMap' in 'DAGCombiner::Run' never becomes empty. This is resulting in a runaway state of continuous heap allocation until the process exhausts all system memory. But I can't