similar to: [LLVMdev] Removing metadata in a pass

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>

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

Hi, Ivan: My $0.02. hasZeroCostLooping() disabling unrolling dose not seem to be appropriate for other architectures, at least the one I worked before. You mentioned: >Currently, we cannot detect them because the loop unroller is >unrolling them before entering into the codegen. Looking at its implementation, >it. Could you please articulate why CG fail to recognize it?

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

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

On Mon, Jan 30, 2017 at 4:59 PM Mehdi Amini <mehdi.amini at apple.com> wrote: > > > Another question is about PGO integration: is it already hooked there? > Should we have a more aggressive threshold in a hot function? (Assuming > we’re willing to spend some binary size there but not on the cold path). > > > I would even wire the *unrolling* the other way: just

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

Hi Hal, On 21/11/2012 22:38, Hal Finkel wrote: > ----- Original Message ----- >> From: "Ivan Llopard" <ivanllopard at gmail.com> >> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> >> Sent: Wednesday, November 21, 2012 10:31:07 AM >> Subject: [LLVMdev] Disable loop unroll pass >> >> Hi, >> >> We've a

Hi Shuxin, Eli, On 22/11/2012 03:19, Shuxin Yang wrote: > Hi, Ivan: > > My $0.02. hasZeroCostLooping() disabling unrolling dose not seem > to be > appropriate for other architectures, at least the one I worked before. I appreciate your feed-back. Could you give an example where building a hw loop is not appropriate for your target? > > You mentioned: >

> On Jan 30, 2017, at 4:56 PM, Dehao Chen <dehao at google.com> wrote: > > > > On Mon, Jan 30, 2017 at 3:56 PM, Chandler Carruth <chandlerc at google.com <mailto:chandlerc at google.com>> wrote: > On Mon, Jan 30, 2017 at 3:51 PM Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> On Jan 30,

On 16/01/2014, 23:47 , Andrew Trick wrote: > > On Jan 15, 2014, at 4:13 PM, Diego Novillo <dnovillo at google.com > <mailto:dnovillo at google.com>> wrote: > >> Chandler also pointed me at the vectorizer, which has its own >> unroller. However, the vectorizer only unrolls enough to serve the >> target, it's not as general as the runtime-triggered

Recollected the data from trunk head with stddev data and more threshold data points attached: Performance: stddev/mean 300 450 600 750 403 0.37% 0.11% 0.11% 0.09% 0.79% 433 0.14% 0.51% 0.25% -0.63% -0.29% 445 0.08% 0.48% 0.89% 0.12% 0.83% 447 0.16% 3.50% 2.69% 3.66% 3.59% 453 0.11% 1.49% 0.45% -0.07% 0.78% 464 0.17% 0.75% 1.80% 1.86% 1.54% Code size: 300 450 600 750 403 0.56% 2.41% 2.74% 3.75%

----- Original Message ----- > From: "Ivan Llopard" <ivanllopard at gmail.com> > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Wednesday, November 21, 2012 10:31:07 AM > Subject: [LLVMdev] Disable loop unroll pass > > Hi, > > We've a target which has hardware support for zero-overhead loops. > Currently, we

hi, In "LoopUnrollPass.cpp", when trying to reduce unroll count to meet the unroll threshold requirement in line 200 and line 206, variable "CurrentThreshold" is used in the computation, instead of the variable "Threshold", which is defined by: // Determine the current unrolling threshold. While this is normally set // from UnrollThreshold, it is overridden to

Hi, Ivan: Sorry for deviating the topic a bit. As I told you before I'm a LLVM newbie, I cannot give you conclusive answer if the proposed interface is ok or not. My personal opinion on these two interface is summarized bellow: - hasZeroCostLoop() pro: it is clearly state the HW support. con: Having zero cost loop doesn't imply the benefit HW loop could achieve.

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, We've a target which has hardware support for zero-overhead loops. Currently, we cannot detect them because the loop unroller is unrolling them before entering into the codegen. Looking at its implementation, it seems that it checks if it is profitable to unroll it or not based on certain parameters. Given that zero cost loops building is based more or less on the same constraints

I had suggested having size metrics from somewhat larger applications such as Chrome, Webkit, or Firefox; clang itself; and maybe some of our internal binaries with rough size brackets? On Wed, Feb 1, 2017 at 4:33 PM Dehao Chen <dehao at google.com> wrote: > With the new data points, any comments on whether this can justify setting > fully inline threshold to 300 (or any other

On Mon, Jan 30, 2017 at 3:56 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Mon, Jan 30, 2017 at 3:51 PM Mehdi Amini via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On Jan 30, 2017, at 10:49 AM, Dehao Chen via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> Currently, loop fully unroller shares the same default

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