similar to: [LLVMdev] Unrolling a loop with unknown upper bound

Thanks for your point that out. I just add DataLayout in my code such as "mod->setDataLayout("e-m:e-i64:64-f80:128-n8:16:32:64-S128");", still no luck. I'm really confused about this. Do I need to add more passes before -loop-unroll? On Sat, Aug 22, 2015 at 11:36 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Aug 22, 2015, at 7:27 AM, Xiangyang

Hi, Mehdi, For example, I have this very simple source code: void foo( int n, int array_x[]) { for (int i=0; i < n; i++) array_x[i] = i; } After I use "clang -emit-llvm -o bc_from_clang.bc -c try.cc", I get bc_from_clang.bc. With my code (using LLVM IRbuilder API), I get bc_from_api.bc. Attachment please find thse two files. I also past the IR here.

Hi Hal, I did opt.exe -S -debug -loop-unroll -unroll-runtime=true -unroll-count=4 csShader.ll and it prints out: Args: opt.exe -S -debug -loop-unroll -unroll-runtime=true -unroll-count=4 csShader.ll Loop Unroll: F[build_cs_5_0] Loop %loop_entry Loop Size = 82 partially unrolling with count: 1 Thanks, Frances On Thu, Oct 15, 2015 at 9:35 PM, Hal Finkel <hfinkel at anl.gov>

Hi, I am trying to do loop unrolling with loops that don't have constant loop counter. It is highly appreciated if anyone can help me on this. What I want to do is to turn loop (n) { <loop body> } into loop (n/4) { <loop body> <loop body> <loop body> <loop body> } loop (n%4) { <loop

Hello, I tried to do some small experiments on the loop unroll transformation. Following is the Test Program. I compiled it as follows: $ opt -loop-rotate -debug-only=loop-unroll -loop-unroll -unroll-count=2 test1.o -S -o test1.s ------------------ int a[1024]; int main() { int i, sum=0; for(i=0; i<1024; ++i) sum += a[i]; printf("%d",sum); } ------------------- I got

I have a loop with convergent instructions with a loop count of 1024. I use pragma to specify unroll count to be 32. However, the loop was unrolled by 512, which results in very long compilation time. In tryToUnrollLoop, there is // If the loop contains a convergent operation, the prelude we'd add // to do the first few instructions before we hit the unrolled loop // is unsafe -- it

Hi, I just tried llvm-3.8 (LLVM SVN Repository). With this version, -fno-rtti can help me to compile my code and -irce can help me to do a better job for loop unrolling. However, I still have one question. If I use Clang to compile a piece of c++ code to .bc and then use 'opt -loop-rotate -loop-unroll -irce', I can get what I want. I mean, there is no conditional branch at the end of each

What component is responsible for loop unrolling, llvm-gcc, or some LLVM pass after GCC? When compiling this function: void printArray( int array[16] ) { for( int i = 0; i < 16; ++ i ) { printf( "%d\n", array[i] ); } } llvm-gcc chooses to unroll this loop, and I don't think it should. It doesn't unroll the loop if there are 17 iterations, only 16. It also produces

In r200270 I added support to unroll conditional stores in the loop vectorizer. It is currently off pending further benchmarking and can be enabled with "-mllvm -vectorize-num-stores-pred=1”. Furthermore, I added a heuristic to unroll until load/store ports are saturated “-mllvm enable-loadstore-runtime-unroll” instead of the pure size based heuristic. Those two together with a patch that

Hi all, Attached herewith is a simple vectorized function with loops performing a simple shuffle. I want all loops (inner and outer) to be unrolled by 2 and as such used -unroll-count=2 The inner loops(with k as the induction variable and having constant trip counts) unroll fully, but the outer loop with (j) fails to unroll. The llvm code is also attached with inner loops fully unrolled. To

Thanks for the explanation. But I am a little confused with the following fact. Can't LLVM keep vectorizable_elements as a symbolic value and convert the loop to say; for(unsigned i = 0; i < vectorizable_elements ; i += 2){ //main loop } for(unsigned i=0 ; i < vectorizable_elements % 2; i++){ //fix up } Why does it have to reason about the range of vectorizable_elements? Even

If count > MAX_UINT-4 your loop loops indefinitely with an increment of 4, I think. On Thu, Oct 13, 2016 at 4:42 PM, Charith Mendis via llvm-dev < llvm-dev at lists.llvm.org> wrote: > So, I tried unrolling the following simple loop. > > int unroll(unsigned * a, unsigned * b, unsigned *c, unsigned count){ > > for(unsigned i=0; i<count; i++){ > > a[i] =

Hello, When we invoke the loop-unroll pass, the compiler is crashing. From the earlier posts in the mailing-list and from the bug reports, it is a known problem. Is there some one working on this bug? -Suresh

A short while ago I wrote about the strange loop unrolling behavior we encountered. The problem was that with -O3, the following loop does not get unrolled if the ifdef'ed dead code is not present. ------------------------------------ extern volatile int v1; int unroll() { int i; int v2 = 0; for(i = 0; i < 3; i++) { if (i == v2) { v1 = 1000; } else { v1 = 1001; }

Hi, In LLVM (using the opt tool), is it possible to force a nested loop be unrolled entirely? Something like a pass option? I have a nested loop with depth of 4, and all trip counts are known at compile time, but so far I've only been able to do this by 4 invocations of the -loop-simplify, -loop-rotate, -loop-unroll passes. Thanks, Ali

Hello, I've come across another example: I'm compiling with clang -S -emit-llvm -std=gnu99 -O3 clang version 2.9 (trunk 118238) Target: x86_64-unknown-linux-gnu Thread model: posix I take the code: int loops(int x) { int ret = 0; for(int i = 0; i < x; i++) { for(int j = 0; j < x; j++) { ret += 1; } } return ret; } and the

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, I found some issues during my testing of "loop unrolling" capabilities of LLVM's opt. Seems like LLVM generates slower code with -O3 since it wrongly decides to unroll a simple loop. With option -Os, no loop unrolling, the output looks well. Code:

Hi all, I'm attempting to perform loop unrolling on a single function using the C++ API. Maybe I missed something in the docs, but I cannot figure out a way to do this. The function I'm working with is very simple, containing a single for loop and not much else. I compiled the function to IR using clang with no optimizations enabled. My initial plan was to first run the IndVarSimplify

I am having a strange problem with loop unrolling. Attached is a small example that demonstrates what happens. There is a for-loop with a known trip count, and some control flow inside the loop. If the condition of the control flow only depends on the loop index and loop invariant variables, the loop is not unrolled. However, if the condition involves potentially loop variant variables, the loop