similar to: [LLVMdev] How to unroll loops in opposite loop nest order

On Jun 5, 2012, at 3:20 AM, Martin Apel <martin.apel at SIMPACK.de> wrote: > I am trying to implement loop unrolling in a context, where lots of constant propagation has taken place. > Unrolling an outer loop might make an inner loop have constant bounds, therefore I want to process the loops > outside in, i.e. from parent loops to nested loops. > Unfortunately the standard loop

Hi Duncan, thanks for the quick reply. I understand, that the generated code is different between the two approaches. But I would still expect IEEE rules to be respected in any case. I do not see any reason why -fPIC -fomit-frame-pointer and the like should have any impact on the results computed by the generated code. Are there any options I can set on the command line of llc to force the

Hi Martin, > thanks for the quick reply. I understand, that the generated code is different > between the two approaches. > But I would still expect IEEE rules to be respected in any case. I do not see > any reason why -fPIC -fomit-frame-pointer > and the like should have any impact on the results computed by the generated code. probably in the direct case you are using the x86

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 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

Hi Martin, > I tried using dragonegg to compile some numerical software of ours. I > tried out two different approaches expecting both would yield the same > results: > 1. gfortran-4.6 -fplugin=dragonegg-3.0 -o test.o test.f (I ommitted a > bunch of additional arguments for brevity) > 2. gfortran-4.6 -fplugin=dragonegg-3.0 -fplugin-arg-dragonegg-emit-ir -S > -o test.ll

Hi all, I stumbled across a peculiarity regarding constant propagation that I don't understand. I'm not sure, if I oversee anything or if it's a missing feature. I have created the following simple test function in C: int times_zero(int a) { return (a * 0); } Compiling this with GCC using dragonegg generates the following code: %int = type i32 define i32 @times_zero(i32 %a)

Hi all, I tried using dragonegg to compile some numerical software of ours. I tried out two different approaches expecting both would yield the same results: 1. gfortran-4.6 -fplugin=dragonegg-3.0 -o test.o test.f (I ommitted a bunch of additional arguments for brevity) 2. gfortran-4.6 -fplugin=dragonegg-3.0 -fplugin-arg-dragonegg-emit-ir -S -o test.ll test.f llc -O0 -o test.s test.ll as

On Fri, Jul 15, 2011 at 12:21 AM, Martin Apel <martin.apel at simpack.de> wrote: > Hi all, > > I stumbled across a peculiarity regarding constant propagation that I don't understand. I'm not sure, if I oversee anything or if it's a missing feature. > > I have created the following simple test function in C: > > int times_zero(int a) > { >  return (a *

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

Hi all, I have tried to use the loop-unroll pass on a large example, but without success. So I have tried on smaller examples, and I did not get more success. My simplest example is attached. It comes from this C code (using llvm-gcc, but similar result with clang): int main (int argc, char *argv[]) { int i; for (i = 0; i!=5; ++i) {} return 0; } I use this command (version 2.8svn, from

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?

Hello... I have a big problem with asterisk. Every time i make a call asterisk does not bridge the zap channels. The zap channel from which i'm calling remains in state:ring and applicaton:dial and the zap channel with the external line configured remains in state:dialling an Application:AppDial. Zap/20-1 agentie s 1 Dialing AppDial (Outgoing Line) 09399 (None) Zap/9-1 int_omg 09399 5 Ring

How do you expect people to be able to tell you if you are using it properly if they can't see how you are using it? Cameron On Jan 12, 2012, at 12:22 PM, Ryan Taylor wrote: > I'm not sure it's a bug. If I don't know if I am properly using it then how would I know it's a bug and not simply a user issue? If it sounds like a bug to you then I will file it. :) > > On

Hi, I try to write a FunctionPass that, among other tasks, has to clone some loops from the current function. How can I obtain the LPPassManager in order to use the CloneLoop function. In a LoopPass this is a parameter for the runOnLoop, but how can I obtain it in a FunctionPass? I tried simply by creating a new instance : ValueMap<const Value *, Value* > VMap;

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

Hi, I've been looking at the new AVR backend lately, and one issue I've found is that all 'load' IR instructions are matched using the 'ld' AVR instruction, including 'load's for lookup tables generated from switches. On the AVR architecture, RAM and the program image are in completely separated namespaces. There's a distinct 'lpm' (Load from Program

change from v3: add x86 vcpu preempted check patch change from v2: no code change, fix typos, update some comments change from v1: a simplier definition of default vcpu_is_preempted skip mahcine type check on ppc, and add config. remove dedicated macro. add one patch to drop overload of rwsem_spin_on_owner and mutex_spin_on_owner. add more comments thanks boqun and Peter's suggestion.

change from v3: add x86 vcpu preempted check patch change from v2: no code change, fix typos, update some comments change from v1: a simplier definition of default vcpu_is_preempted skip mahcine type check on ppc, and add config. remove dedicated macro. add one patch to drop overload of rwsem_spin_on_owner and mutex_spin_on_owner. add more comments thanks boqun and Peter's suggestion.

It looks like this problem only exists on nested loops, ideas? On Thu, Jan 12, 2012 at 11:44 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Is it not a good idea to try and extract loops that have multiple exits? > > > On Thu, Jan 12, 2012 at 10:44 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > >> I am trying to use ExtractLoop() but I am getting segFaults: