similar to: [LLVMdev] [llvm] r184698 - Add a flag to defer vectorization into a phase after the inliner and its

On Jun 24, 2013, at 11:01 AM, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > Hi, > > I wanted to start a discussion about the following issue since I am not sure about what to do about it: > > The loop-vectorizer has the potential to make code a quite a bit bigger (esp. in cases where we don’t know the loop count or whether pointers alias). > Chandler has

----- Original Message ----- > Hi, > > I wanted to start a discussion about the following issue since I am > not sure about what to do about it: > > The loop-vectorizer has the potential to make code a quite a bit > bigger (esp. in cases where we don’t know the loop count or whether > pointers alias). > Chandler has observed this in snappy where we have a simple

On Mon, Jun 24, 2013 at 11:01 AM, Arnold Schwaighofer < aschwaighofer at apple.com> wrote: > In <http://llvm.org/viewvc/llvm-project?view=revision&revision=184698> > Chandler introduced a flag so that we can run the vectorizer after all CG > passes. This would prevent the inline from seeing the vectorized code. > Just for the record, I have no real expectation that

----- Original Message ----- > > > > > On Jun 24, 2013, at 11:01 AM, Arnold Schwaighofer < > aschwaighofer at apple.com > wrote: > > > > Hi, > > I wanted to start a discussion about the following issue since I am > not sure about what to do about it: > > The loop-vectorizer has the potential to make code a quite a bit > bigger (esp. in

On Jun 24, 2013, at 2:32 PM, Hal Finkel <hfinkel at anl.gov> wrote: > I assume that we're taking about nsw, etc. The fact that SCEV assumes nsw in some cases has led to problems (PR16130 has some history on this), and I don't understand why SCEV's unique-ifying/commoning expressions implies that it needs to drop the flags. Yes I am talking about the ability to maintain

On Mon, Jun 24, 2013 at 12:32 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > In > > <http://llvm.org/viewvc/llvm-project?view=revision&revision=184698> > > Chandler introduced a flag so that we can run the vectorizer after > > all CG passes. This would prevent the inline from seeing the > > vectorized code. > > There are obviously several issues

----- Original Message ----- > > > > On Jun 24, 2013, at 4:24 PM, Hal Finkel < hfinkel at anl.gov > wrote: > > > > > Indvars should ideally preserve NSW flags whenever possible. However, > we don't want to rely on SCEV to preserve them. SCEV expressions are > implicitly reassociated and uniqued in a flow-insensitive universe > independent of the

Sent from my iPhone... On Jun 25, 2013, at 8:14 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> >> >> >> On Jun 24, 2013, at 4:24 PM, Hal Finkel < hfinkel at anl.gov > wrote: >> >> >> >> >> Indvars should ideally preserve NSW flags whenever possible. However, >> we don't want to

On Jun 24, 2013, at 3:09 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > The inliner, GVN, and the loop passes run together, *iteratively*. They are neither before or after one another. And this is important as it allows iterative simplification in the inliner. It is one of the most critical optimizations for C++ code that LLVM does. > > We can't sink all of the loop

On Jun 24, 2013, at 4:24 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> Indvars should ideally preserve NSW flags whenever possible. However, >> we don't want to rely on SCEV to preserve them. SCEV expressions are >> implicitly reassociated and uniqued in a flow-insensitive universe >> independent of the def-use chain of values. SCEV simply can't >>

> > Just for the record, I have no real expectation that this is a good idea yet... But it's hard to collect numbers without a flag of some kind, and it's also really annoying to craft this flag given the current pass manager, so I figured I would get a skeleton in place that folks could experiment with, and we could keep or delete based on this discussion and any numbers. I agree.

On Mon, Jun 24, 2013 at 2:59 PM, Nadav Rotem <nrotem at apple.com> wrote: > I agree. The vectorizer is a *lowering* pass, and much like LSR and it > loses information. A few months ago some of us talked about this and came > up with a general draft for the ideal pass ordering. > Where? On the mailing list? > If I remember correctly the plan was that the second half of the

Hi, I am going through analysis on unswitching + vectorization. For the below test, llvm unswitches successfully but fails to vectorize the loop after unswitching. Llvm bails out saying "Found an outside user" apparently which is the value of 'tmp'. int i, w, x[1000], y[1000],tmp; void fn() { for (i = 0; i < 1000; i++) { if (w==1) { y[i] = 1; tmp = i*2; }

On 5/10/2018 10:44 PM, Gopalasubramanian, Ganesh via llvm-dev wrote: > > Hi, > > I am going through analysis on unswitching + vectorization. > > For the below test, llvm unswitches successfully but fails to > vectorize the loop after unswitching. > > Llvm bails out saying “Found an outside user” apparently which is the > value of ‘tmp’. > > int i, w, x[1000],

* Looks like some sort of pass ordering issue; it will vectorize if indvars runs sometime between loop unswitch and the vectorizer. That insight is helpful. I scheduled Canonicalization of induction variable before loop vectorization and could get the loop vectorized. The indvars are heavily dependent on SCEV. If there a scalar like tmp which is of real type, we may not be able to get the

Hi folks, I'm trying to analyse this piece of IR: for.body: ; preds = %for.body, %entry %indvars.iv = phi i64 [ 0, %entry ], [ %indvars.iv.next, %for.body ] %0 = shl nsw i64 %indvars.iv, 1 %arrayidx = getelementptr inbounds i32* %b, i64 %0 %1 = load i32* %arrayidx, align 4, !tbaa !1 %add = add nsw i32 %1, %I %arrayidx3 = getelementptr

On Wed, Sep 19, 2012 at 6:30 PM, Andrew Trick <atrick at apple.com> wrote: > > On Sep 19, 2012, at 2:18 PM, Preston Briggs <preston.briggs at gmail.com> > wrote: > > On Tue, Sep 18, 2012 at 10:59 PM, Andrew Trick <atrick at apple.com> wrote: > >> >> On Sep 18, 2012, at 8:21 PM, Preston Briggs <preston.briggs at gmail.com> >> wrote:

On Tue, Sep 18, 2012 at 10:59 PM, Andrew Trick <atrick at apple.com> wrote: > > On Sep 18, 2012, at 8:21 PM, Preston Briggs <preston.briggs at gmail.com> > wrote: > > Given the following SCEV, > > *(sext i32 {2,+,1}<nw><%for.body> to i64)* > > > from the following C source, > > *void strong3(int *A, int *B, int n) {* > * for (int i =

On Wed, Jan 15, 2014 at 5:30 PM, Nadav Rotem <nrotem at apple.com> wrote: > Was the vectorizer successful in unrolling the loop in quantum_sigma_x? I > wonder if 'size’ is typically high or low. No. The vectorizer stated that it wasn't going to bother with the loop because it wasn't profitable. Specifically: LV: Checking a loop in "quantum_sigma_x" LV: Found a

Hi Vesa, The pass IndVars changes the induction variables to allow SCEV to analyze them and enable other optimizations. This is the canonicalization phase. Later on, LSR lowers the canonicalized induction variables to induction variables that map nicely to the target's addressing modes. In many cases it can remove some of the induction variables. I suspect that the loop vectorizer does