similar to: [LLVMdev] Header problem on GCC 4.3

Hi, I recently cleaned up the includes from the loop unrolling code, and this also removed this include. It seems it's included implicitely somehow here, because I have not problems compiling (running gcc 4.1). However, the proper include is #include <climits>, since we're in c++, not C. Could someone add this include to lib/Transforms/Scalar/LoopUnroll.cpp ? Gr. Matthijs

> However, the proper include is #include <climits>, since we're in c++, not C. > > Could someone add this include to lib/Transforms/Scalar/LoopUnroll.cpp ? Done (r51145). Maybe this should go into the release too. Ciao, Duncan.

Hi, > > Could someone add this include to lib/Transforms/Scalar/LoopUnroll.cpp ? > Done (r51145). Maybe this should go into the release too. I don't think the unroll changes ended up in the release, so this fix shouldn't need to either. Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature

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

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

Hi, I ran into this issue recently and wanted to know if it was a bug or expected behavior. In the R600 backend's TargetTransformInfo implementation, we were setting UnrollingPreferences::Count = UINT_MAX. This was a mistake as we should have been setting UnrollingPreferences::MaxCount instead. However, as a result of setting Count to UINT_MAX, this loop would be unrolled 15 times: if (b

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

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, I am trying to set loop unrolling as a required pass. AU.addRequired<LoopUnroll>(); should I include any header file? How can I be possessive that "LoopUnroll" is the name I need ? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090606/aaab7bd1/attachment.html>

The loop rotation pass does modify the function, which I'm guessing means that a FunctionPassManager can be used to run LoopPasses (this is not obvious to me after looking through the FunctionPassManager code). Unfortunately none of the other passes I'm using (ScalarEvolution, LCSSA, IndVarSimplify, and LoopUnroll) appear to have an effect. I verified that the function can be loop

On 1/18/17 3:55 PM, Davide Italiano via llvm-dev wrote: > On Tue, Jan 17, 2017 at 6:02 PM, Mikhail Zolotukhin > <mzolotukhin at apple.com> wrote: >> Hi, >> >> Continuing recent efforts in understanding compile time slowdowns, I looked at some historical data: I picked one test and tried to pin-point commits that affected its compile-time. The data I have is not 100%

Ah but how did you compile the clang-4.0 you were using? Does it run faster if you compile it with clang-4.0? :) On Fri, Jan 20, 2017 at 4:09 AM, Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > On this topic, I just tried to build ToT with clang-3.9.1 and clang-4.0 > and the total time to complete `ninja clang` on this machine went from > 12m54s to

I'm building llvm in MSVS 2008. LoopUnroll.cpp includes UnrollLoop.h line 23: #include "llvm/Transforms/Utils/UnrollLoop.h" but there's no UnrollLoop.h anywhere to be found. My svn tree is synced to TOT. What am I missing?

On Aug 26, 2010, at 11:05 AM, Akira Hatanaka wrote: > Is there a class or function that generates an add or sub instruction in a target-independent manner? No. Such a target hook does not exist. > I am looking for something similar to TargetInstrInfo::copyRegTpReg but one that creates other types of instructions. It almost sounds like you should be writing a normal optimization pass

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

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, On Fri, Jun 4, 2010 at 5:18 AM, Pekka Nikander <pekka.nikander at nomadiclab.com> wrote: >  Would the best way be to add an option to -loop-unroll, and hack away at lib/Transforms/Utils/LoopUnroll.cpp? Instead, the better alternative is to write another pass similar to LoopUnrollPass.cpp (say LoopPeelPass.cpp) and add new option -loop-peel. The new pass could use llvm::UnrollLoop()

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