search for: r184698

...code?). If we really feel > that we can't adjust the current heuristic without breaking other things, > then we could add some metadata to make the cost estimator ignore the > vector loop preheader, but I'd prefer adjusting the inlining thresholds, > etc. The commit message for r184698 said that the flag was for > experimentation purposes, and I think that's fine, but this should not be > the solution unless it really produces better non-inlined code as well. If all we are doing is inlining first in order to tweak the cost model for inlining, then I agree with everyth...

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 7:16 PM, Andrew Trick <atrick at apple.com> wrote: > I don't want to start a centi-thread yet, but here's a very rough idea > (leaving many things out): I actually like the look of this. I'll hack things around so we have a flag (or set) we can use to experiment. It would be great to get the bits factored out of IndvarSimplify so that we can run

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

...n the non-vectorized code?). If we really feel that we can't adjust the current heuristic without breaking other things, then we could add some metadata to make the cost estimator ignore the vector loop preheader, but I'd prefer adjusting the inlining thresholds, etc. The commit message for r184698 said that the flag was for experimentation purposes, and I think that's fine, but this should not be the solution unless it really produces better non-inlined code as well. > > I see some potential issues: > > * We run a loop pass later again with the associated compile time >...

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

On Jun 24, 2013, at 3:09 PM, Chandler Carruth <chandlerc at gmail.com> wrote: 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

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

> > 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.

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

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

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

...st in the process. > > Is this behavior a problem with SimplifyIndVar or is this expected? > How easy would it be to change this, and do you have any pointers to > where I should have to look? Coincidentally, we were just discussing this issue as part of the "Re: [LLVMdev] [llvm] r184698 - Add a flag to defer vectorization into a phase after the inliner and its" thread. I believe that Andy mentioned something about how he felt this should fix fixed. -Hal > > Cheers, > Jonas > > _______________________________________________ > LLVM Developers mailing lis...

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 memory copying loop (that may overlap). We vectorize this loop and then this

Hello, I'm using LLVM to reason about memory safety of programs. One goal is to prove that certain array accesses are always safe. Currently, one of these proofs fails because of a missing no-signed-wrap (nsw) flag. I found that it has been "lost" during the SimplifyIndVar pass. Here's the example: int foo(int a[]) { int sum = 0; for (int i = 0; i < 1000; ++i)