similar to: [LLVMdev] Unnatural loops with O0

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

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

It seems that tail duplication can make a reducible CFG irreducible (example 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

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

hi, Florian Brandner wrote: > Dan Gohman wrote: >> On Wed, May 23, 2007 at 12:23:38AM -0700, Chris Lattner wrote: >>> Right. The original Value*'s are preserved in the DAG, but dropped when >>> MachineInstrs are created. We could add a machineoperand to capture this >>> Value* if desired. >> Another benefit of keeping the original Value*'s

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 here the failures. Anyway there is a suggested "revision" to use on PowerPC 32bit on Linux ? [...] llvm[0]: ***** Completed Release Build + make check llvm[0]: Running test suite make[1]: Entering directory `/home/llvm/work/src/llvm-2.8/test' Making a new site.exp file... Making LLVM 'lit.site.cfg' file... Making LLVM unittest

Dear all, Attached notunrolled.ll is a module containing reduction kernel. What I'm trying to do is to unroll it in such way, that partial reduction on unrolled iterations would be performed on register, and then stored to memory only once. Currently llvm's unroller together with all standard optimizations produce code, which stores value to memory after every unrolled iteration, which is

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

I tried to manually assign each of 3 arrays a unique TBAA node. But it does not seem to help: alias analysis still considers arrays as may-alias, which most likely prevents the desired optimization. Below is the sample code with TBAA metadata inserted. Could you please suggest what might be wrong with it? Many thanks, - D. marcusmae at M17xR4:~/forge/llvm$ opt -time-passes -enable-tbaa -tbaa

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 =

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

Reid Spencer wrote: > Have you modified the makefile in any way? Note that sse.expantfft.bc should be sse.expandfft.bc no, did'nt change it. the typo before seems to be an error while copying from the terminal. i've cleaned everything and tried again. this is the messsage: [brandner:/localtmp/brandner/dev/llvm-test:529] make -j1 TEST=nightly 2>&1 | tee report.nightly.raw.out

On Fri, 04 May 2007 14:37:53 +0200 Florian Brandner <fbrandne at mail.tuwien.ac.at> wrote: >hello, > >i've problems running the llvm-test suite using debian linux and make >3.81. it works fine on my laptop, running openSuse and make 3.81. > >i already tried to install make 3.75 and 3.79, both did not work. > >the error message is: > >make[1]: *** No rule to

hello, i've problems running the llvm-test suite using debian linux and make 3.81. it works fine on my laptop, running openSuse and make 3.81. i already tried to install make 3.75 and 3.79, both did not work. the error message is: make[1]: *** No rule to make target `Output/sse.expantfft.bc', needed by `Output/sse.expandfft.linked.rbc'. Stop. using make -p, i see that

hi, i know it took a while, but here is a patch that adds a list of source values to machine instructions. i modified the DAGISelEmiter to automatically catch regular loads/stores. custom instructions and loads/stores rewritten by the lowering pass are not automatically captured. during the instruction selection a source value operand is added to the DAG for patterns matching a load/store.

I think what's happening is BranchFolder::MaintainLiveIns is using a forward analysis on top of these missing kill flags, and updating the BB-live-ins/live-outs with 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

On Mon, 22 Oct 2007, Dale Johannesen wrote: > In principle I think keeping IEEE float and double in an endian- > independent form in the IR files is a good idea. BUT: I'm told > retaining the ability to use files in the existing format is a > requirement (so floats still need to occupy 8 bytes). Since ARM target > doesn't currently work that one is a reasonable

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