search for: loopunroller

Hi, I'm having some problems cross-compiling from ppc (OS X) to x86 object files and to ia64, at all. I'd appreciate some advice as to whether or not I'm actually supposed to be able to do this, and what's wrong if so. Here's how I configured it: ../llvm-darcslocal/llvm/configure --with-llvmgccdir=$LLVMGCCDIR --prefix=$HOME/Documents/hpcl/LLVM/install The results work fine

Hi, just a quick question about the intent of the ApproximateLoopSize() function in LoopUnroll.cpp: If a loop contains debug stoppoint intrinsics, does it make sense to count them? My understanding is that they are removed when not running under llvm-db anyway, so we probably shouldn't make size judgements based on them. Is that right, or am I missing something? Anyway, if I'm right,

OK, I noticed a few problems with my previous email, so I will boil the question down: What I want to do is compile for x86 and ia64 from darwin. I also want to load my own passes into opt and llc. Should I be using llvmc at all here, or should I be doing something like llvmgcc -> gccas -> opt -> llc ? I've given up on the filetype=obj argument, so now the problem is that llc is

Hi All, the attached patch performs the splitting in the proposed manner. before applying the patch, please execute svn cp lib/Transforms/Scalar/LoopUnroll.cpp lib/Transforms/Utils/UnrollLoop.cpp to make the patch apply and preserve proper history. Transforms/Utils/UnrollLoop.cpp contains the unrollLoop function, which is now used by the LoopUnroll pass. I've also moved the

I've done some minimal testing on FreeBSD 8.x i386. When running make check I get: # of expected passes 2188 # of unexpected failures 1 # of expected failures 6 The error output is: Running /usr/cvsports/devel/llvm/work/llvm-2.2/test/Transforms/LoopUnroll/dg.exp ... FAIL: /usr/cvsports/devel/llvm/work/llvm-2.2/test/Transforms/LoopUnroll/2007-11-05-Crash.ll for

LLVMers, The next version of the 2.2 prerelease is available for testing: http://llvm.org/prereleases/2.2/ Please see my last email for testing directions: http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-January/012249.html Please complete all testing by February 10th at 5PM PST. Thanks! -Tanya

Hi, the attached patch splits the loop unroll pass into a LoopUnroll superclass that implements the unrolling mechanism, and a SimpleLoopUnroll subclass implementing the current policy. This split is modeled after the split between Inliner and SimpleInliner. The superclass currently still finds out the TripCount and TripMultiple, and passes those, together with the Loop in question, to a policy

Hello Matthijs, Separating mechanism from policy is a good thing for the LoopUnroll pass. Instead of moving the policy to a subclass though, I think it'd be better to move the mechanism, the unrollLoop function, out to be a standalone utility function, with the LoopInfo object passed in explicitly. FoldBlockIntoPredecessor would also be good to make into a standalone utility function, since

Hi, please find an updated patch attached that incorporates the (trivial) changes introduced by r50696 and which makes this patch apply cleanly again. Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: split-unroll.diff Type: text/x-diff Size: 14660 bytes Desc: not available URL:

Hello, I wrote my own pass which needs to do some loop unrolling. I can perform loop unrolling via opt: opt -mem2reg -loops -loop-simplify -loop-rotate -lcssa -loop-unroll -unroll-count=50 mytest.bc -o mytest.bc This command works perfectly. However, what I really want is to produce the **same behavior** but from my own pass (i.e., I don't want to use opt). I wrote a Module pass which

On Aug 6, 2012, at 6:04 AM, Jorge Navas <navas at comp.nus.edu.sg> wrote: > > Hello, > > I wrote my own pass which needs to do some loop unrolling. > > I can perform loop unrolling via opt: > > opt -mem2reg -loops -loop-simplify -loop-rotate -lcssa -loop-unroll > -unroll-count=50 mytest.bc -o mytest.bc > > This command works perfectly. > >

Hello Matthijs, On May 9, 2008, at 3:47 AM, Matthijs Kooijman wrote: > Hi All, > > the attached patch performs the splitting in the proposed manner. > before applying the patch, please execute > svn cp lib/Transforms/Scalar/LoopUnroll.cpp lib/Transforms/Utils/ > UnrollLoop.cpp > to make the patch apply and preserve proper history. > > Transforms/Utils/UnrollLoop.cpp

Dan, On May 6, 2008, at 5:56 PM, Dan Gohman wrote: > This should still make it easy to write new unrolling passes with > custom heuristics, but it would also be more flexible for passes to > do unrolling in combination with other transformations. Do you mean unrolling during other transformation or before/after other transformation ? Do you have specific example in mind ? Thanks, -

On May 6, 2008, at 8:30 PM, Devang Patel wrote: > Dan, > > On May 6, 2008, at 5:56 PM, Dan Gohman wrote: > >> This should still make it easy to write new unrolling passes with >> custom heuristics, but it would also be more flexible for passes to >> do unrolling in combination with other transformations. > > Do you mean unrolling during other transformation or

Hi Dan, > in the AMD 5.5 What's that? Got a link? Google only finds some kind of golf cart powered by the "Advanced Motors & Drivers 5.5" engine :-) Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL:

Hi Dan, please find an updated patch attached (don't forget to run the svn cp command I posted earlier, before applying this patch). I've incorporated all the changes we've discussed. Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL:

On May 13, 2008, at 3:17 AM, Matthijs Kooijman wrote: > Hi Dan, > > please find an updated patch attached (don't forget to run the svn > cp command > I posted earlier, before applying this patch). > > I've incorporated all the changes we've discussed. Looks good. I just committed it as r51083. Thanks, Dan

On May 7, 2008, at 1:08 AM, Matthijs Kooijman wrote: > Hi Dan, > >> This should still make it easy to write new unrolling passes with >> custom heuristics, but it would also be more flexible for passes to >> do unrolling in combination with other transformations. > Agreed. > > To shed some light on my specific requirements, I am working with an > architecture

Is anyone currently working on overhauling the command-line processing code? We're currently having some design issues with this component, and I'd like to start a larger conversation on it. For context, I am talking from an "LLVM as a library" perspective instead of an "LLVM as a set of tools" perspective. In a nut-shell, the problems we are facing are as follows:

Hi Dan, > This should still make it easy to write new unrolling passes with > custom heuristics, but it would also be more flexible for passes to > do unrolling in combination with other transformations. Agreed. To shed some light on my specific requirements, I am working with an architecture that has only limited support for loops and control flow. This means that loop unrolling is not