similar to: [LLVMdev] powerpc32: llvm-2.8 make-check failures

On Nov 13, 2010, at 9:37 AM, acrux wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > here the failures. Anyway there is a suggested "revision" to use on > PowerPC 32bit on Linux ? > Looks like you didn't build support for all targets in when you built it? -eric > [...] > llvm[0]: ***** Completed Release Build > + make check >

On Thursday 08 May 2008 18:33:48 Adrian Prantl wrote: > we noticed that llvmgcc4.2-2.2 sometimes generates non-natural loops > when compiling to bytecode without any optimizations. Apparently what > happens is that the loop header is duplicated, which results in two > entry points for the loop. this is actually a problem with the tailduplication pass of llvm. it does not consider

On Jun 11, 2008, at 6:27 AM, Florian Brandner wrote: > On Thursday 08 May 2008 18:33:48 Adrian Prantl wrote: >> we noticed that llvmgcc4.2-2.2 sometimes generates non-natural loops >> when compiling to bytecode without any optimizations. Apparently what >> happens is that the loop header is duplicated, which results in two >> entry points for the loop. > > this is

On Fri, 02 Dec 2011 13:23:07 -0600 Hal Finkel <hfinkel at anl.gov> wrote: _omissis__ > > > > ciao Hal, > > thanks a lot for your support. > > i'll try your last suggestion. > > > > Btw, adding -UPPC to my system cxx flags i.e.: > > export CXXFLAGS="$CXXFLAGS -UPPC" > > > > i got, instead, some tests error: > >

FAIL: /usr/home/jeffc/llvm/obj/../test/Regression/Transforms/LoopStrengthReduce/dont_insert_redundant_ops.ll: FAIL: /usr/home/jeffc/llvm/obj/../test/Regression/Transforms/LoopStrengthReduce/dont_reduce_bytes.ll:

Hello, This patch aims to improve compile time performance by increasing the SCEV vector size in LoopStrengthReduce. It is observed that the BaseRegs vector size is 4 in most cases, and elements are frequently copied when it is initialized as SmallVector<const SCEV *, 2> BaseRegs. Our benchmark results show that the compilation time performance improved by ~0.5%. Patch by Wan Xiaofei.

The only non-empty output file I can find is ops_after_indvar.ll.out: Instruction does not dominate all uses! %idx = cast int %idx to uint ; <uint> [#uses=1] %tmp. = mul uint %idx, 4 ; <uint> [#uses=1] Instruction does not dominate all uses! %tmp. = mul uint %idx, 4 ; <uint> [#uses=1] %tmp.1 = add uint %P,

The error given: ..\..\..\..\trunk\lib\Transforms\Scalar\LoopStrengthReduce.cpp(1016) : error C2668: 'abs' : ambiguous call to overloaded function f:\Program Files\Microsoft Visual Studio 8\VC\include\math.h(539): could be 'long double abs(long double)' f:\Program Files\Microsoft Visual Studio 8\VC\include\math.h(491): or 'float abs(float)'

This might be hard cases making bad law, but the loop: void f (unsigned short *x, int *l) { int c = *l; int i; for (i = 0; i < c; i++) if (x[i]) x[i]++; } is converted to decrement-and-branch form by LoopStrengthReduce while: void f (unsigned short *x, int *l) { int i; for (i = 0; i < *l; i++) if (x[i]) x[i]++; } isn't.

No error messages with these failures? Can you look into the output files? Reid. On Sat, 2005-07-30 at 14:04 -0700, Jeff Cohen wrote: > FAIL: > /usr/home/jeffc/llvm/obj/../test/Regression/Transforms/LoopStrengthReduce/dont_insert_redundant_ops.ll: > > > FAIL: > /usr/home/jeffc/llvm/obj/../test/Regression/Transforms/LoopStrengthReduce/dont_reduce_bytes.ll: > > >

This is related to an issue in loop strength reduction [1] that I've been trying to fix on and off for a while. [1] has a more detailed description of the issue and an example, but briefly put, I want LSR to consider formulae that have "Zext T" as base and/or scale registers, and to appropriately rate such formulae. My first attempt[2] at fixing this was buggy and had to be

Hi, I was building LLVM with gcc 6.1.1 recently and it was spitting out some warnings relating to misleading indention that caught my eye. This wasn't a fresh build so I may have missed some. I've CC'ed the authors of the potentially misleading lines so they can decide what do about the warnings (if anything). I'm wondering if clang-format is making some inappropriate choices

On Tue, May 12, 2009 at 5:01 PM, Dale Johannesen <dalej at apple.com> wrote: > > On May 12, 2009, at 3:09 PMPDT, OvermindDL1 wrote: > >> The error given: >> >> ..\..\..\..\trunk\lib\Transforms\Scalar\LoopStrengthReduce.cpp(1016) : >> error C2668: 'abs' : ambiguous call to overloaded function >> >> It should be rather obvious from the

The following failures are consistent on buildbot (and my local box). The Clang one I think it's assuming an Intel box, the other two look like the FileCheck are not good enough. http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/4305 Clang :: CodeGen/compound-assign-overflow.c LLVM :: Transforms/LoopStrengthReduce/post-inc-icmpzero.ll LLVM ::

On May 12, 2009, at 3:09 PMPDT, OvermindDL1 wrote: > The error given: > > ..\..\..\..\trunk\lib\Transforms\Scalar\LoopStrengthReduce.cpp(1016) : > error C2668: 'abs' : ambiguous call to overloaded function > > It should be rather obvious from the message. The error is in > LoopStrengthReduce.cpp on line 1016: > (unsigned(abs(SInt)) < SSInt || (SInt %

On May 12, 2009, at 5:01 PMPDT, OvermindDL1 wrote: > On Tue, May 12, 2009 at 5:01 PM, Dale Johannesen <dalej at apple.com> > wrote: >> >> On May 12, 2009, at 3:09 PMPDT, OvermindDL1 wrote: >> >>> The error given: >>> >>> ..\..\..\..\trunk\lib\Transforms\Scalar >>> \LoopStrengthReduce.cpp(1016) : >>> error C2668:

Greetings everybody, I'm at beginner level with LLVM and tried to build the sources from SVN revision 54920 on Fedora 9 (kernel 2.6.25-14.fc9.x86_64) running on Intel Q6600 @ 2.40GHz processor. LLVM build using 'make -j 4' was successful. However, during 'make check', a test case failed. The relevant snippets appear below. Can someone please point me to any links on how the

On Tue, Jan 8, 2013 at 3:04 PM, Renato Golin <renato.golin at linaro.org> wrote: > The following failures are consistent on buildbot (and my local box). [...] > LLVM :: Transforms/LoopStrengthReduce/post-inc-icmpzero.ll > LLVM :: Transforms/LoopStrengthReduce/2012-07-18-LimitReassociate.ll It is interesting that I don't see this on my ARM box. Instead I see these: Failing

Hello LLVM, This is a proposal for a new pass that improves performance and code size in some nested loop situations. The pass is target independent. >From the description in the file header: This optimization finds loop exit values reevaluated after the loop execution and replaces them by the corresponding exit values if they are available. Such sequences can arise after the

Hi debug-info folks, Time for another update on the variable location "instruction referencing" implementation I've been doing, see this RFC [0, 1] for background. It's now at the point where I'd call it "done" (as far as software ever is), and so it's a good time to look at what results it produces. And here are the scores-on-the-doors using llvm-locstats, on