similar to: [LLVMdev] Transforming Loops

Hi all, I just noticed that LICM does not hoist/sink the following store out of the loop: int array[20]; int i; for (i = 0; i<100; i++) { array [0] = 0; } The getElementPtr instruction is hoisted out of the loop; the store is not. Did I miss something obvious? Bitcode file attached. Generated using LLVM 2.5 and llvm-gcc -c -emit-llvm

Chris Lattner schrieb: > On Aug 21, 2009, at 3:04 AM, Marc Brünink wrote: >>> This isn't really possible. The issue is that MemDep doesn't just >>> "analyze your function". It is designed to be as lazy as possible, >>> which means that it only does analysis when a query is performed. This >>> means that if you have

On Fri, Aug 21, 2009 at 10:48 AM, Marc Brünink<marc at bruenink.de> wrote: >>> actually my problem is easier. So I still have hope that it is possible: >>> >>> MemDep->Pass1->Pass2 >>> >>> Pass1 uses MemDep. Pass2 only uses Pass1. Eventually, Pass2 changes the >>> code. Unfortunately, non-local dependencies of MemDep might point to

2009/10/27 Marc Brünink <marc at bruenink.de> > Hi all, > > I just noticed that LICM does not hoist/sink the following store out of the > loop: > > int array[20]; > int i; > for (i = 0; i<100; i++) { > array [0] = 0; > } > > The getElementPtr instruction is hoisted out of the loop; the store is not. > Did I

On Oct 27, 2009, at 9:26 AM, Nick Lewycky wrote: > 2009/10/27 Marc Brünink <marc at bruenink.de> > Hi all, > > I just noticed that LICM does not hoist/sink the following store out > of the loop: > > int array[20]; > int i; > for (i = 0; i<100; i++) { > array [0] = 0; > } > > The getElementPtr instruction

Hello all, I’m pretty new to LLVM. I'm writing a pass for loop optimization. I clone and rearrange loops, setting the cloned loop as the original loop’s parent. This can be done multiple times, until there is no more work to do. The trouble is, after the first time I do this, the cloned loop's SCEVs become unknown types when they should be AddRecExpr. If I re-run the whole pass on the

Hello, Quick question to see if I haven't missed anything: I would like convert counting down loops, i.e. loops with a constant -1 step value, to counting up loops, because the vectoriser is able to better deal with these loops (see e.g. D76838 that I was discussing today with Ayal). It looks like LoopSimplifyCFG and IndVarSimplify don't do this. So was just curious if I haven't

On Mon, Feb 27, 2012 at 9:30 AM, Benjamin Kramer <benny.kra at googlemail.com> wrote: > > On 27.02.2012, at 17:13, Николай Лихогруд wrote: > >> Dear LLVM, >> >>     Consider two loops with one interation - >>     First with constant lower bound, second with usual non-constant lower bound: >> >>     int main(int argc, char ** argv) >>     {

On 27.02.2012, at 18:49, Eli Friedman wrote: > On Mon, Feb 27, 2012 at 9:30 AM, Benjamin Kramer > <benny.kra at googlemail.com> wrote: >> >> On 27.02.2012, at 17:13, Николай Лихогруд wrote: >> >>> Dear LLVM, >>> >>> Consider two loops with one interation - >>> First with constant lower bound, second with usual

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 8/8/2017 1:37 PM, Friedman, Eli wrote: > On 8/8/2017 10:22 AM, Geoff Berry via llvm-dev wrote: >> Hi all, >> >> I'm looking into resolving a FIXME in the LoopDataPrefetch (and FalkorMarkStridedAccesses) pass by marking both of these passes as preserving the ScalarEvolution analysis. Unfortunately, when this change is made, LSR will generate different code. One of the

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 all, I'm looking into resolving a FIXME in the LoopDataPrefetch (and FalkorMarkStridedAccesses) pass by marking both of these passes as preserving the ScalarEvolution analysis. Unfortunately, when this change is made, LSR will generate different code. One of the root causes seems to be that SCEV will return different nsw/nuw flags for the same Value, depending on what order the

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 Jimmy, It's good to know that the problem is not specific to the case I ran into. May be you can provide your example as well, since Philip seems to be interested in some specific examples. If the assertion in getAddrExpr is deemed necessary, then I think a condition check would be the next best solution as it helps client code guard against such cases and make alternative arrangements to

When compile the following case and look at the SCEV analysis, I notice that the first two loops don't have a LoopInvariantBackedgeTakenCount (surprising) and the last one does (not surprising, except in the context of the first two examples). *void p4(int *A, int *B, long int n) {* * for (char i = 0; i < n; i++) {* * A[i + 2] = i;* * *B++ = A[i];* * }* *}* * * *void p5(int *A, int

Ok. To go back to the original issue, would it be meaningful to add a SCEVUMax(0, BTC) on the final BTC computed by SCEV? So that it does not use "negative values"? On Wed, Aug 15, 2018 at 2:40 PM Friedman, Eli <efriedma at codeaurora.org> wrote: > On 8/15/2018 2:27 PM, Alexandre Isoard wrote: > > I'm not sure I understand the poison/undef/UB distinctions. >

For reference, the case with a variable loop count is filed as PR27894: https://llvm.org/bugs/show_bug.cgi?id=27894 And the case with a constant loop count is filed as PR27899: https://llvm.org/bugs/show_bug.cgi?id=27899 On Thu, Jun 2, 2016 at 7:48 AM, Demikhovsky, Elena via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I implemented IV simplification with FP SCEV and uploaded a new

Thanks for sharing the known problem. I think to solve the problem properly, we need to fully understand why that assumption about dominance is there and the implications of removing it. It would be good if you could be more specific about your idea of nullptr or SCEV_unknown (eg which function would return those values and when), but returning nullptr from getAddExpr or getSCEVAtScope may be

Hi everyone, I hope to implement a feature to transform an IR with "while" or "for" loops to a new IR with no loop. Instead, I just want to use if-else statements in the new IR to implement the original semantics. I can easily write a transform pass to handle the 1-level loop case, but for nested loops it seems a little harder. Can you show me some hints? Thank you very