search for: tailduplicate

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 regarded as dead and no tail duplication happens. However, as far as I

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 run, the...

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

...instruction and then simply replaced %vreg2 with %vreg0 since they are connected through a PHI, but since the register classes differ, the resulting code is wrong. I've managed to get around this by inserting a COPY in TailDuplication but I don't know what the proper fix is to this. In TailDuplicatePass::ProcessPHI: const TargetRegisterClass *RC = MRI->getRegClass(DefReg); + const TargetRegisterClass *SrcRC = MRI->getRegClass(SrcReg); + + // If the register class of the PHI src is wider than the PHI def + // then we can't just use PHI src instead of PHI def in the cloned + /...

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

...>"/"<code>volatile store</code>") On Wed, Oct 31, 2012 at 10:17 AM, <dag at cray.com> wrote: > 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. Aft...

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

...pass to make irreducible graphs > reducible. Was that ever implemented? There isn't any such pass in trunk LLVM. One could potentially be added, but it would have to be a high-quality implementation, and we'd have to measure the costs and benefits carefully. > ; "opt -inline -tailduplicate" makes an irreducible CFG from this code I can't reproduce the issue, and I can't see how tailduplicate could possibly make your function irreducible, since it shouldn't be able to introduce a loop into a function without any loops. Can you include the output you're getting,...

...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 @test() {...

Hi, I think there might be a bug in the tail duplicator (called from MachineBlockPlacement in my case), when duplicating a block that contains an implicit fall-through. Suppose you have the following blocks BB#1: Predecessors according to CFG: BB#2 ... conditional_branch <BB#3> < implicit fall-through to BB#2 > Successors according to CFG: BB#2 BB#3 BB#2:

Eli Friedman <eli.friedman at gmail.com> writes: >> Ah. So is the MachineFunction version expected to work correctly? > > It's part of the default set of CodeGen passes. It is? Was that true in 3.1? I can't see where it is initialized in llc. I probably missed something important. :) Thanks! -David

http://llvm.org/viewvc/llvm-project/llvm/tags/RELEASE_31/final/lib/CodeGen/Passes.cpp?revision=156747&view=markup void TargetPassConfig::addMachineSSAOptimization() { // Pre-ra tail duplication. if (addPass(EarlyTailDuplicateID) != &NoPassID) printAndVerify("After Pre-RegAlloc TailDuplicate"); /// Add passes that optimize machine instructions after register allocation. void TargetPassConfig::addMachineLateOptimization() { // Branch folding must be run after regalloc and prolog/epilog insertion. i...

Good morning! After updating and recompiling my copy of the LLVM trunk I noticed that the line "_passManager.add(llvm::createTailDuplicationPass());" in my code fails with the following assertion: Assertion failed: NormalCtor && "Cannot call createPass on PassInfo without default ctor!", file D:\Workspace\llvmtrunk\include\llvm/PassSupport.h, line 111 This behavior

Thanks again. I executed the following command line llc -O3 comb.ll.bc -debug-pass=Arguments and got Pass Arguments: -targetdata -targetpassconfig -no-aa -tbaa -targetlibinfo -basicaa -collector-metadata -machinemoduleinfo -machine-branch-prob -preverify -domtree -verify -loops -loop-simplify -scalar-evolution -loop-simplify -iv-users -loop-reduce -gc-lowering -unreachableblockelim

...>> reducible. Was that ever implemented? > > There isn't any such pass in trunk LLVM. One could potentially be > added, but it would have to be a high-quality implementation, and we'd > have to measure the costs and benefits carefully. > >> ; "opt -inline -tailduplicate" makes an irreducible CFG from this code > > I can't reproduce the issue, and I can't see how tailduplicate could > possibly make your function irreducible, since it shouldn't be able to > introduce a loop into a function without any loops. Can you include > the out...

Does LLVM have loop multiversioning ? it seems it does not with clang++ -O3 -mllvm -debug-pass=Arguments program.c -c bash-4.1$ clang++ -O3 -mllvm -debug-pass=Arguments fast_algorithms.c -c clang-3.6: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated Pass Arguments: -datalayout -notti -basictti -x86tti -targetlibinfo -no-aa -tbaa -scoped-noalias

Hi, > I executed the following command line > > llc -O3 comb.ll.bc -debug-pass=Arguments > > and got > > Pass Arguments: -targetdata -targetpassconfig -no-aa -tbaa > -targetlibinfo -basicaa -collector-metadata -machinemoduleinfo > -machine-branch-prob -preverify -domtree -verify -loops -loop-simplify > -scalar-evolution -loop-simplify -iv-users -loop-reduce

I am reviving this thread because I am seeing the same thing (unnatural loops produced by llvm-gcc), but it is not limited to -O0 -- I am seeing it for -O2 and -O3 as well. Some of my research work is relying on LoopInfo to provide loop information for all loops, but it is missing these loops. Is there any work in the pipeline that aims to fix this? Many thanks, Marc On Sat, Jun 21, 2008 at

Hello, I've been trying to figure out how to reproduce the results of a single clang -O3 compilation to a binary with a multi-step process using opt. Specifically I have: clang -O3 foo.c -o foo.exe which I want to replicate with: clang -O0 -c -emit-llvm foo.c opt -O3 foo.bc -o foo_o.bc clang foo_o.bc -o foo.exe Any hints / suggestions on what additional flags I need to produce the same

Hi all, I have faced a little bit of a strange transformation from the TailDuplicatePass In CodeGen. When the pass clones the contents of TailBB into PredBB, the bundled instructions in TailBB are not bundled in PredBB. I think the reason why it is not bundled is that the 'DuplicateInstruction' function does not set up the flag of the first instruction of the bundle in...