[LLVMdev] Proposal for ""llvm.mem.vectorize.safelen"

[Hal Finkel]

----- Original Message -----
> From: "Arnold Schwaighofer" <aschwaighofer at apple.com>
> To: "Johannes Doerfert" <doerfert at cs.uni-saarland.de>
> Cc: llvmdev at cs.uiuc.edu, "Arch Robison" <arch.robison at intel.com>
> Sent: Wednesday, August 20, 2014 11:29:16 AM
> Subject: Re: [LLVMdev] Proposal for ""llvm.mem.vectorize.safelen"
> 
> 
> > On Aug 20, 2014, at 9:18 AM, Johannes Doerfert
> > <doerfert at cs.uni-saarland.de> wrote:
> > 
> > On 08/20, Arnold Schwaighofer wrote:
> >> 
> >> 
> >> This means you would allow lexically forward dependencies which
> >> complicates things (this would need more infrastructure in
> >> clang). You need to carry over “source order” from the front-end.
> >> Because the dependency is loop carried llvm would be allowed to
> >> move loads and stores within the loop:
> > This should not be that hard (see below).
> > 
> >> Lexical forward dependency:
> >> 
> >> #pragma vectorize safelen(4)
> >> for (i = …) {
> >>   a[i] = b[i] + z[i];
> >>   c[i]  = a[i-1] + 1;
> >> }
> >> 
> >> LLVM might tranform this loop to:
> >> 
> >> for (i = …) {
> >>   c[i]  = a[i-1] + 1;
> >>   a[i] = b[i] + z[i];
> >> }
> >> 
> >> if we now vectorize this (without knowledge of the orignal source
> >> order) we get the wrong answer:
> >> 
> >> for (i = …) {
> >>   c[i]  = a[i-1:i+2] + 1;
> >>   a[i:i+3] = b[i] + z[i];
> >> }
> >> 
> >> Alternatively, the metadata loop.vectorize.safelen would have to
> >> prevent any such reordering of accesses i.e. any pass that
> >> reorders memory accesses would have to be aware of it which is
> >> fragile.
> > Could we number the memory accesses for such loops (e.g., in
> > clang)?
> > Adding metadata to each memory access which points to the safelen
> > annotation and contains an increasing constant would be similarly
> > fragile as other constructions we use at the moment. However, it
> > would
> > allow us to determine iff the current order is still the original
> > one or
> > not. (At least if I did not miss anything).
> 
> 
> This is what I meant by carry over source order. You either teach
> clang to number accesses or you have an early llvm pass that does
> the same.

We must do this directly in the frontend. Relying on another pass run early would be bad because it would introduce a hard-to-enforce contract affecting correctness.

Also, we should probably allow for missing access numbers, so long as everything is in order (because the optimizer might eliminate some of them). Some memory-access instructions might also have more than one access number (after GVN, vectorization, etc.), and we should allow for that.

 -Hal

> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

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