search for: scevcomplexitycompar

I just filed bug 7872 about non-scalability of the LSR analysis algorithms. It may be related to bug 6727. The fundamental problem appears to be re-running SCEV analyses such as properlyDominates and SCEVComplexityCompare over and over again on large SCEV expressions. Memoizing results for SCEVComplexityCompare appears to help significantly but that is much harder to do with things like properlyDominates. Is anyone actively looking at LSR compile time issues? LLVM 2.7 is taking on the order of 30 minutes to opti...

...ed, Aug 11, 2010 at 2:48 PM, David Greene <dag at cray.com> wrote: > I just filed bug 7872 about non-scalability of the LSR analysis > algorithms. It may be related to bug 6727. > > The fundamental problem appears to be re-running SCEV analyses such as > properlyDominates and SCEVComplexityCompare over and over again on large > SCEV expressions. Memoizing results for SCEVComplexityCompare appears > to help significantly but that is much harder to do with things like > properlyDominates. > > Is anyone actively looking at LSR compile time issues? LLVM 2.7 is > taking on th...

...configured llvm-gcc: $ ../llvm-gcc/configure --prefix=/pkg/build/llvm/install --program-prefix=llvm- --enable-llvm=/pkg/build/llvm/llvm-obj --enable-languages=c,c++ attempted to build llvm-gcc: $ make -j15 ... cc1: /pkg/build/llvm/llvm/lib/Analysis/ScalarEvolution.cpp:511: bool<unnamed>::SCEVComplexityCompare::operator()(const llvm::SCEV*, const llvm::SCEV*) const: Assertion `0 && "Unknown SCEV kind!"' failed. ../../llvm-gcc/libdecnumber/decNumber.c:5591: internal compiler error: Aborted This is all with llvm and llvm-gcc source from svn. I have tried gcc-4.2.4 and gcc-4.3.2. ENA...

...such cases. > > Thanks in advance for any response. Nice test case. I tried printing the SCEV… oops. I haven’t seen a case this bad, but I know you’re not the first to run into this problem. There are two steps in GroupByComplexity, sorting (std::sort) and grouping (N^2). The sort calls SCEVComplexityCompare::compare() which can make multiple recursive calls for nodes with multiple operands. This looks like it could be a disaster for expressions that are not strictly trees--exponential in the size of the DAG. If you just have a very large tree with many similar looking subexpressions, then I’m not su...

Hi, > $ make -j15 do you really have 15 CPUs? If not, this will most likely just slow things down. > cc1: /pkg/build/llvm/llvm/lib/Analysis/ScalarEvolution.cpp:511: > bool<unnamed>::SCEVComplexityCompare::operator()(const llvm::SCEV*, > const llvm::SCEV*) const: Assertion `0 && "Unknown SCEV kind!"' > failed. > ../../llvm-gcc/libdecnumber/decNumber.c:5591: internal compiler error: Aborted > > This is all with llvm and llvm-gcc source from svn. Since the SCEV...

...for any response. > > > Nice test case. I tried printing the SCEV… oops. I haven’t seen a case this > bad, but I know you’re not the first to run into this problem. > > There are two steps in GroupByComplexity, sorting (std::sort) and grouping > (N^2). > > The sort calls SCEVComplexityCompare::compare() which can make multiple > recursive calls for nodes with multiple operands. This looks like it could > be a disaster for expressions that are not strictly trees--exponential in > the size of the DAG. > Yes, this is why i suggested computing some deterministic "complexit...

...or such cases. Thanks in advance for any response. Nice test case. I tried printing the SCEV... oops. I haven't seen a case this bad, but I know you're not the first to run into this problem. There are two steps in GroupByComplexity, sorting (std::sort) and grouping (N^2). The sort calls SCEVComplexityCompare::compare() which can make multiple recursive calls for nodes with multiple operands. This looks like it could be a disaster for expressions that are not strictly trees--exponential in the size of the DAG. If you just have a very large tree with many similar looking subexpressions, then I'm no...

Hello, Scott > Yes, so I have read -- which is why I initially installed gcc-4.2.4. > My original post was looking for help on how to use gcc-4.2.4. Some > suggestions were made, but I was not able to get everything built. It > seems that despite attempting to configure with everything pointing to > gcc-4.2.4 (and not the system gcc 4.1.2), at some point in the build, >

...er, so I stuck with j15. I guess there might be some context switching when threads are blocking on memory or IO. I could be imagining the speedups though because of some sort of placebo effect. >> cc1: /pkg/build/llvm/llvm/lib/Analysis/ScalarEvolution.cpp:511: >> bool<unnamed>::SCEVComplexityCompare::operator()(const llvm::SCEV*, >> const llvm::SCEV*) const: Assertion `0 && "Unknown SCEV kind!"' >> failed. >> ../../llvm-gcc/libdecnumber/decNumber.c:5591: internal compiler error: Aborted >> >> This is all with llvm and llvm-gcc source from sv...

On Wed, May 6, 2009 at 12:51 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Even if you'll succeed, most probably LLVM will be miscompiled. gcc > 4.1.2 is known buggy: http://llvm.org/docs/GettingStarted.html#brokengcc > Yes, so I have read -- which is why I initially installed gcc-4.2.4. My original post was looking for help on how to use gcc-4.2.4. Some

Hi, We have a benchmark where there are 128 MAD computations in a loop. (See the attached IR.) Creating SCEVs for these expressions takes a long time, making the compile time too long. E.g., running opt with the "indvars" pass only takes 45 seconds. It seems that the majority of the time is spent in comparing the complexity of the expression operands to sort them. I realize that the

I got the following error while compiling llvm and clang under cygwin. /cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/Release+Asserts/lib/libLLVMMCJIT.a(SectionMemoryManager.o):SectionMemoryManager.cpp:(.text+0x3b): undefined reference to `__register_frame'