search for: taildup

...electing target for module 'No available targets are compatible with this triple, see -version for the available targets.'. Please use the -march option to explicitly pick a target. - -- ******************** Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90 FAIL: LLVM :: Transforms/TailDup/if-tail-dup.ll (5207 of 5496) ******************** TEST 'LLVM :: Transforms/TailDup/if-tail-dup.ll' FAILED ******************** Script: - -- opt < /home/llvm/work/src/llvm-2.8/test/Transforms/TailDup/if-tail-dup.ll -tailduplicate | llc -march=x86 -o /home/llvm/work/src/llvm-2.8/test/T...

...e 'No available targets are compatible with this triple, see -version for the available targets.'. Please use the -march option to explicitly pick a target. > - -- > > ******************** > Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90 > FAIL: LLVM :: Transforms/TailDup/if-tail-dup.ll (5207 of 5496) > ******************** TEST 'LLVM :: Transforms/TailDup/if-tail-dup.ll' FAILED ******************** > Script: > - -- > opt < /home/llvm/work/src/llvm-2.8/test/Transforms/TailDup/if-tail-dup.ll -tailduplicate | llc -march=x86 -o /home/llvm/work...

...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 loops at all, and thus duplicates loop headers. the result is that two paths now lead into the loop --> it is not natural anymore and further loop optimizations fail. besides, the tailduplication pass does not invalidate the loopinfo analysis, as...

Hello everybody, 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. Since this could obstruct subsequent loop optimizations, it might be interesting to further investigate this behavior. To show the problem, I have

...ced 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 loops at all, and thus duplicates loop headers. the result > is that > two paths now lead into the loop --> it is not natural anymore and > further > loop optimizations fail. I think the patch was reverted because using loop...

...ed together in register coalescing. * 3 locations are un-necessarily dropped due to conservative tracking of PHI values (the code in D86814, can be fixed with more C++). * 2 of the sample didn't actually have a dropped location; instead they preserved an undef debug instruction in early-taildup, and my scripts picked this up as dropping a location. * 2 locations aren't tracked by InstrRefBasedLDV through a block that's out of scope, meaning the location never covers instructions that are in scope. VarLocBasedLDV is vulerable to this too, but MachineSink can drop a DBG...

...ter coalescing. > * 3 locations are un-necessarily dropped due to conservative tracking of PHI > values (the code in D86814, can be fixed with more C++). > * 2 of the sample didn't actually have a dropped location; instead they > preserved an undef debug instruction in early-taildup, and my scripts picked > this up as dropping a location. > * 2 locations aren't tracked by InstrRefBasedLDV through a block that's > out of scope, meaning the location never covers instructions that are in > scope. VarLocBasedLDV is vulerable to this too, but MachineSi...

Hi, while reading the TailDuplication pass, I found a check that looks rather pointless. TailDuplication looks at an unconditional branch instruction, BI. It performs a number of checks on the successor of this branch instruction, Dest. One of this checks is counting the number of predecessor. If this count is zero, Dest is re...

...69 # of unexpected successes 2 # of expected failures 13 I see a lot of "FAIL:" messages, and they are somehow always related to -march=x86 flag for llc. Following is an example of these kind of errors>> FAIL: /local/space2/llvm_toolchain/llvm/test/Transforms/TailDup/if-tail-dup.ll Failed with exit(1) at line 1 while running: llvm-as < /local/space2/llvm_toolchain/llvm/test/Transforms/TailDup/if-tail-\ dup.ll | opt -tailduplicate | llc -march=x86 -o if-tail-dup.ll.tmp -f llc: for the -march option: : Cannot find option named 'x86'! I'm not...

Do the buildbots only build debug components? I am seeing lots of this on trunk with release-style builds: [x86_64-off-opt]: Failed with signal(SIGABRT) at line 1 [x86_64-off-opt]: while running: llvm-as < /ptmp/dag/llvm- project.official/llvm/tags/RELEASE_25/test/Transforms/TailDup/basictest2.ll | opt -tailduplicate -disable-output [x86_64-off-opt]: Value still in symbol table! Type = 'i64' Name = 'poscnt.1' [x86_64-off-opt]: Value still in symbol table! Type = 'i64' Name = 'tmp.289' [x86_64-off-opt]: llvm-as: /ptmp/dag/llvm- project.official...

...I was *completely* wrong here. CodeGen correctly preserves the ordering of blocks from IR, *unless* it can do folding, etc. That's right. However, the CFG changes quite a bit during CodeGen. Switches can be lowered into branch trees, multiple passes can split critical edges, and then there is taildup and tailmerge. An IR code layout algorithm simply doesn't know the final CFG. > As for why it should be an IR pass, mostly because once the selection dag runs through the code, we can never recover all of the freedom we have at the IR level. To start with, splicing MBBs around requires kno...

On 2009-02-24 03:28, Kshitij Sudan wrote: > I am new to LLVM, and I'm trying to compile llvm and llvm-gcc from > subversion on a Solaris10/SPARC machine. I have already tried building > llvm-2.4 on this machine, but it failed. > > I then tried the subversion sources (rev. # 65253 fro llvm and > rev#65263 for llvm-gcc) and llvm at least builds correctly ( I however > have

...ometimes 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 loops at all, and thus duplicates loop headers. the result > > is that > > two paths now lead into the loop --> it is not natural anymore and > > further > > loop optimizations fail. > > I think the patc...

...s having with Rafael about a problem we have been seeing trying to compile an "interpreter" type of program with clang. It was producing a huge number of spills, something we had seen in llvm 2.8, and it seemed to have recurred in 3.0. Following Rafael's advice we added -disable-early-taildup to llc and the spills disappeared. It would be nice if we could pass such switches directly through the clang command line. Is there a way to do that? thanks for your help Rafael! /maurice 2012/2/21 Rafael Ávila de Espíndola <rafael.espindola at gmail.com> > On 21/02/12 11:35 AM, Mauri...

...mple below). Is that intentional? Are there other optimizations that have that property? Is irreducibility a problem for existing LLVM passes? It looks like there was once an open project for a pass to make irreducible graphs reducible. Was that ever implemented? - Mark ; "opt -inline -tailduplicate" makes an irreducible CFG from this code @x = weak global float 0.0 define internal fastcc void @foo(float %f) { entry: %b = fcmp ogt float %f, 0.0 br i1 %b, label %then, label %continue then: store float 0.0, float* @x br label %continue continue: ret void } define void @tes...

...an incorrect set of registers. Then when the stackmaps liveness analysis happens, it's not doing anything wrong, but it starts with the wrong set of live registers and will propagate those to the point of the patchpoint/stackmap. For now it might be possible to just fix BranchFolder (and also TailDuplicatePass::TailDuplicate) to use a backwards analysis as well, but if we really wanted to make sure that the liveness information was accurate when the stackmaps code looks at it, wouldn't we need to get rid of anything that supports forward liveness analysis? On Mon, Oct 13, 2014 at 8:27 PM,...

On Tue, Oct 18, 2011 at 2:59 PM, Cameron Zwarich <zwarich at apple.com> wrote: > On Oct 18, 2011, at 2:53 AM, Chandler Carruth wrote: > > > Hello, > > > > I'm working on basic-block placement optimizations based on branch > probability information. I've run into a stumbling block though. One of the > existing passes to do this, essentially a dead pass

...buildbots only build debug components?  I am seeing lots of this on > trunk with release-style builds: > > [x86_64-off-opt]: Failed with signal(SIGABRT) at line 1 > [x86_64-off-opt]: while running:  llvm-as < /ptmp/dag/llvm- > project.official/llvm/tags/RELEASE_25/test/Transforms/TailDup/basictest2.ll | > opt -tailduplicate -disable-output > [x86_64-off-opt]: Value still in symbol table! Type = 'i64' Name = 'poscnt.1' > [x86_64-off-opt]: Value still in symbol table! Type = 'i64' Name = 'tmp.289' > [x86_64-off-opt]: llvm-as: /ptmp/dag/llvm...

We used to have an LLVM-IR pass did tail duplication (http://llvm.org/viewvc/llvm-project/llvm/tags/RELEASE_29/final/lib/Transforms/Scalar/TailDuplication.cpp) It was not used and went away with 3.0. The documentation is out of date. commit f940a1a869b4fe6f857e7fd8aeb97e7b7e9b390e Author: Rafael Espindola <rafael.espindola at gmail.com> Date: Tue Aug 30 23:03:45 2011 +0000 Remove the old tail duplication pass. It is not used and...

I'm reading up on LLVM's implementation of tail duplication and the description is confusing: http://llvm.org/docs/Passes.html -tailduplicate: Tail Duplication This pass performs a limited form of tail duplication, intended to simplify CFGs by removing some unconditional branches. This pass is necessary to straighten out loops created by the C front-end, but also is capable of making other code nicer. After this pass is ru...