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

Arnold Schwaighofer
Wed, 20 Aug 2014 15:29:48 -0000

> On Aug 20, 2014, at 8:08 AM, Robison, Arch <arch.robison at
intel.com> wrote:
>
>> I recommend that you send patches for an implementation
>> (including the Loop::GetAnnotatedVectorSafelen function
>> and associated updates to the vectorizer) for review.
>
> I expect to send the patches for review later this week.
>
>> Make sure to remember LangRef updates!
>
> Thanks for the reminder.
>
>> Also, looking at the original proposal again, I see no reason
>> to restrict this to an i32: we might as well allow it to be an
>> i64 obviously we don't have billion-lane vectors, but the
>> metadata can also be useful for other kinds of analysis).
>
> I doubt there is much advantage between knowing the minimum loop-carried
> dependence difference is 1u<<31 or 1u<<63.  Unless there is a
clear
> need for the higher values less than infinity, It would seem simpler
> for now to adopt the same conventions as llvm.loop.vectorize.width
> so that some processing infrastructure can be shared easily.
>
>> I don't like using the name 'safelen' however. I can
forgive OpenMP
>> for choosing such a short name because people need to type it,
>> but I'd prefer that the metadata have a more-descriptive name.
>> minimum_dependency_distance is perhaps better.
>
> I'm open to naming suggestions, though I'm wondering if sticking
with
> what is now a term of art in OpenMP might be the least of all evils,
> because the semantics turn out to be a little more subtle than
> just a minimum dependence distance.  My current wording of the semantics
> for safelen of k are:
>
>  /// The loop can be assumed to have no loop-carried
>  /// lexically backward dependencies with distance less than k.

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:

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.

>
> - Arch D. Robison
>  Intel Corporation
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev