search for: decomposemultidimrefs

Looks like this suite is pretty empty :-) May I delete it or should it be beefed up some time? Cheers, Gabor

...to decomposed into a sequence of single index operations so that they can be exposed to GCSE and LICM. This transformation obscures the indexing behavior of the code, so the right place to do this is within each back-end, on LLVM code just before instruction selection. There is a pass called DecomposeMultiDimRefs (which seems to have been incorrectly moved to lib/Target/SparcV9/) which does this transformation. It's used by the SparcV9 back end before instr. selection but is not specific to Sparc. Running this, followed by LICM and GCSE should address this problem. --Vikram

...e of single index > operations so that they can be exposed to GCSE and LICM. This > transformation obscures the indexing behavior of the code, so the > right place to do this is within each back-end, on LLVM code just > before instruction selection. > > There is a pass called DecomposeMultiDimRefs (which seems to have been > incorrectly moved to lib/Target/SparcV9/) which does this > transformation. It's used by the SparcV9 back end before instr. > selection but is not specific to Sparc. Running this, followed by > LICM and GCSE should address this problem. > > --...

On Tue, 22 Feb 2005, Vikram S. Adve wrote: >> The second issue is that we need to do redundancy elimination and hoisting >> on operations that are only exposed once instruction selection is >> performed. Getelementptr expansion is just ONE particular case of this, >> but it can happen with any instructions (including the use of large integer >> (or any FP)

...ex operations so that they >> can be exposed to GCSE and LICM. This transformation obscures the indexing >> behavior of the code, so the right place to do this is within each >> back-end, on LLVM code just before instruction selection. >> >> There is a pass called DecomposeMultiDimRefs (which seems to have been >> incorrectly moved to lib/Target/SparcV9/) which does this transformation. >> It's used by the SparcV9 back end before instr. selection but is not >> specific to Sparc. Running this, followed by LICM and GCSE should address >> this proble...

LLVMers, The LLVM 2.1 pre-release version2 is now available: http://llvm.org/prereleases/2.1/version2/ You can help test this pre-release by doing one of the following: 1) Download llvm-2.1, llvm-test-2.1, and the appropriate llvm-gcc4.0 binary. Run "make check" and the full llvm-test suite (make TEST=nightly report). 2) Download llvm-2.1, llvm-test-2.1, and the llvm-gcc4.0 source.

When I increased COLS to the point where the loop could no longer be unrolled, the selection dag code generator generated effectively the same code as the default X86 code generator. Lots of redundant imul/movl/addl sequences. It can't clean it up either. Only unrolling all nested loops permits it to be optimized away, regardless of code generator. Jeff Cohen wrote: > I noticed

.../test/Transforms/ConstantMerge/dg.exp ... Running /home/jo/Delta/llvm/test/Transforms/CorrelatedExprs/dg.exp ... Running /home/jo/Delta/llvm/test/Transforms/DeadArgElim/dg.exp ... Running /home/jo/Delta/llvm/test/Transforms/DeadStoreElimination/dg.exp ... Running /home/jo/Delta/llvm/test/Transforms/DecomposeMultiDimRefs/dg.exp ... Running /home/jo/Delta/llvm/test/Transforms/GCSE/dg.exp ... Running /home/jo/Delta/llvm/test/Transforms/GVN/dg.exp ... Running /home/jo/Delta/llvm/test/Transforms/GVNPRE/dg.exp ... Running /home/jo/Delta/llvm/test/Transforms/GlobalDCE/dg.exp ... Running /home/jo/Delta/llvm/test/Transform...

Here's what's left on Linux (GCC 4.1.0), after all updates that went into the branch: Running /proj/llvm/build/../llvm/test/Regression/CFrontend/dg.exp ... FAIL: /proj/llvm/build/../llvm/test/Regression/CFrontend/2004-02-12- LargeAggregateCopy.c.tr: gccas: /proj/llvm/build/../llvm/lib/VMCore/Function.cpp:266: unsigned int llvm::Function::getIntrinsicID() const: Assertion `0 &&

I noticed that fourinarow is one of the programs in which LLVM is much slower than GCC, so I decided to take a look and see why that is so. The program has many loops that look like this: #define ROWS 6 #define COLS 7 void init_board(char b[COLS][ROWS+1]) { int i,j; for (i=0;i<COLS;i++) for (j=0;j<ROWS;j++) b[i][j]='.';

LLVMers, The 2.1 pre-release (version 1) is available for testing: http://llvm.org/prereleases/2.1/version1/ I'm looking for members of the LLVM community to test the 2.1 release. There are 2 ways you can help: 1) Download llvm-2.1, llvm-test-2.1, and the appropriate llvm-gcc4.0 binary. Run "make check" and the full llvm-test suite (make TEST=nightly report). 2) Download

...tMerge/dg.exp ... Running /home/edwin/llvm-svn/llvm/test/Transforms/CorrelatedExprs/dg.exp ... Running /home/edwin/llvm-svn/llvm/test/Transforms/DeadArgElim/dg.exp ... Running /home/edwin/llvm-svn/llvm/test/Transforms/DeadStoreElimination/dg.exp ... Running /home/edwin/llvm-svn/llvm/test/Transforms/DecomposeMultiDimRefs/dg.exp ... Running /home/edwin/llvm-svn/llvm/test/Transforms/GCSE/dg.exp ... Running /home/edwin/llvm-svn/llvm/test/Transforms/GVN/dg.exp ... Running /home/edwin/llvm-svn/llvm/test/Transforms/GVNPRE/dg.exp ... Running /home/edwin/llvm-svn/llvm/test/Transforms/GlobalDCE/dg.exp ... Running /home/edwi...