[llvm] r193853 - LoopVectorizer: If dependency checks fail try runtime checks

[Hal Finkel]

----- Original Message -----
> 
> 
> On 11/01/13, Hal Finkel   wrote:
> > ----- Original Message -----
> > > 
> > > On Oct 31, 2013, at 10:36 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> > > 
> > > > Arnold,
> > > > 
> > > > FWIW, this looks related to a question that I asked earlier
> > > > today:
> > > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/067083.html
> > > > 
> > > 
> > > The array bounds check is only added when the dependency check
> > > fails.
> > > Once we extend SCEV for your example, in whatever way we decide
> > > to
> > > do that, we won’t emit these checks anymore.
> > > 
> > > > If a guard already exists (as in the example from my post), and
> > > > the
> > > > vectorizer also adds one, does anything after the vectorizer
> > > > clean
> > > > that up?
> > > > 
> > > 
> > > The runtime checks we add are different from the guard you added
> > > in
> > > your example. Not as clever. The loop vectorizer’s runtime checks
> > > just test no-overlapping'ness of the accesses in the loop. We
> > > don’t
> > > take dependency information into account for building those
> > > checks.
> > 
> > Do the runtime checks account for the store-to-load forwarding
> > issue?
> 
> Yes (indirectly), because we check that the range of memory that two
> accesses touch don't overlap.
> 
> 
> for (i =0; i <  n; )
>  a[f(i)] = ...
>  ... = a[g(i)]
> 
> 
> then we test
> 
> 
>   &a[f(0)] ... &a[f(n)]   does not overlap &a[g(0)] ... &a[g(n)]
> 
> 
> In  your case, if 'k < 2047' this test would fail.

Ah, okay, now I understand. Thanks! This really is a total-overlap check, not just a negative dependence check.

 -Hal

> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory