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

[Arnold Schwaighofer]

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