similar to: SCEV/IndVars Code Owner Nomination

> On May 25, 2016, at 4:17 PM, Andrew Trick via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I would like to nominate Sanjoy Das as code owner of Scalar Evolution and Induction Variable Simplification. > > Scalar Evolution has never had an official code owner, but does regularly need in depth review. Over the past year and a half, Sanjoy has made fantastic contributions

> On May 25, 2016, at 4:27 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ----- Original Message ----- >> From: "Andrew Trick via llvm-dev" <llvm-dev at lists.llvm.org> >> To: "llvm-dev" <llvm-dev at lists.llvm.org> >> Sent: Wednesday, May 25, 2016 6:17:54 PM >> Subject: [llvm-dev] SCEV/IndVars Code Owner

----- Original Message ----- > From: "Andrew Trick via llvm-dev" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Wednesday, May 25, 2016 6:17:54 PM > Subject: [llvm-dev] SCEV/IndVars Code Owner Nomination > > I would like to nominate Sanjoy Das as code owner of Scalar Evolution > and Induction Variable

On 05/26/2016 02:23 AM, Mikhail Zolotukhin via llvm-dev wrote: > >> On May 25, 2016, at 4:27 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> ----- Original Message ----- >>> From: "Andrew Trick via llvm-dev" <llvm-dev at lists.llvm.org> >>> To: "llvm-dev" <llvm-dev at lists.llvm.org> >>>

Hi, I'm working on a slow-compile problem caused by SCEV (PR28830), and I need your suggestions on how to fix it. The loop below causes ScalarEvolution::getMulExpr to hang. int get(unsigned n) { unsigned i, j, mult = 1; for (i = 0; i < 1; i++) { for (j = 0; j < 30; j++) { mult *= n++; } } return mult; } the inner loop is completed unrolled

Hi all, It looks like the induction variable simplification pass prefers doing a zero-extension to compute the wider trip count of loops when extending the IV. This can sometimes result in loss of information making ScalarEvolution's analysis conservative which can lead to missed performance opportunities. For example, consider this loopnest- int i, j; for(i=0; i< 40; i++) for(j=0;

Hi! By only two cases I mean , that in exiting block when computing the condition related to PHI node I can expect only icmp on one of incoming values or on phi node itself... I tried to come up with some more complex examples but I always receive only these two cases, that is why I am asking. This problem still relates to the problem of all induction, cumulative and so on variables in loop. SCEV

On 19 January 2011 13:01, Dan Gohman <gohman at apple.com> wrote: > > On Jan 18, 2011, at 12:32 AM, Nick Lewycky wrote: > > > Hi, > > > > I tracked down a bug in indvars where we weren't updating SCEV properly. > The attached patch shows the fix to this bug with a testcase, but it also > causes five new test failures. > > Indvars isn't

On Jan 19, 2011, at 2:03 PM, Nick Lewycky wrote: > On 19 January 2011 13:01, Dan Gohman <gohman at apple.com> wrote: > > On Jan 18, 2011, at 12:32 AM, Nick Lewycky wrote: > > > Hi, > > > > I tracked down a bug in indvars where we weren't updating SCEV properly. The attached patch shows the fix to this bug with a testcase, but it also causes five new test

Hello . opt -indvars pass does not generate canonical induction variable.  (NULL == loop->getCanonicalInductionVariable();) PLEASE explain why? and how can I fix it? Thanks in advance, Edvard  -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120724/92a28ed5/attachment.html>

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

[+CC Andy] Hi Elena, I don't have any fundamental issues with teaching SCEV about floating point types, but given this will be a major change, I think a high level roadmap should be discussed on llvm-dev before we start reviewing and committing changes. Here are some issues that I think are worth discussing: - Core motivation: why do we even care about optimizing floating point

But even for a very simple loop: int test1 (int *x, int *y, int *z, int k) { int sum = 0; for (int i = 10; i < k; i++) { z[i] = x[i] / y[i]; } return sum; } The initial value of induction variable is not zero after compiling with -O3 -mcpu=power8 x.cpp -S -c -emit-llvm -fno-unroll-loops (see bottom of the email for IR) Also I can write somewhat more complicated loop where step

Hello, I have one more question about how phi nodes and their corresponding ICmp instructions are associated. maybe it is simple, but at first I thought that we always compare against one of incoming value. Is it true that I can have only two cases: %indvars.iv = phi i64 [ %indvars.iv.next, %1 ], [ 0, %0 ] ... %indvars.iv.next = add nuw nsw i64 %indvars.iv, 1 %exitcond = icmp eq i64

> I don't understand why you want to factor out the information, > exactly. It seems like what you need is a function like: > > unsigned getMinLeadingZeros(const SCEV *); > > then, if you want to get the non-extended expression, you can just > apply an appropriate truncation. I assume, however, that I'm missing > something. The problem is not about how to codegen

Hi Hideki, I like this summary overall, thanks. More below. > On May 20, 2016, at 10:04 AM, Saito, Hideki <hideki.saito at intel.com> wrote: > > > To the best of my experience, handling case B (secondary induction) is must-have, and if I’m not mistaken, > people aren’t opposed to that. > > For me, handling case A (primary induction) is “why not?”, but I certainly

+CC llvm-dev On Tue, May 8, 2018 at 2:34 AM, Gal Zohar <Gal.Zohar at ceva-dsp.com> wrote: > I noticed that SCEV, when trying to perform strength reduction, doesn’t use > the ability to prove an induction variable does not signed/unsigned wrap due > to infinite loops. > > Is there an easy way to use the isAddRecNeverPoison function when > determining if strength reduction

Hi, I'm working now on extending SCEV Analysis and adding FP support. At the beginning, I want to vectorize this loop: float fp_inc; float x = init; for (int i=0;i<N;i++){ A[i] = x; x += fp_inc; // Loop invariant variable or constant } In this loop "x" is a FP induction variable. But it is not the "primary" induction and loop trip count is still depends

To the best of my experience, handling case B (secondary induction) is must-have, and if I’m not mistaken, people aren’t opposed to that. For me, handling case A (primary induction) is “why not?”, but I certainly admit that that can be very naïve thinking coming from lack of good understanding on SCEV and their proper usages. Now, let’s assume we can postpone discussion about case A. What is the

Adding support for FP inductions through isInductionPHI() is certainly possible, I have a relatively small local patch that does exactly that for simple fp add-recurrence cases, along with changes to the vectorizer to make it aware of FP inductions. It won't get give you the powerful reasoning capabilities of SCEV, but for the B-like cases it should work. Amara On 20 May 2016 at 19:31, Adam