[llvm-dev] LLVM's loop unroller & llvm.loop.parallel_accesses

[Michael Kruse via llvm-dev]

Trivial example:

#pragma clang loop vectorize(assume_safety)
for (int i = 0; i < n; i+=1) {
  (void)A[0];
}

I hope it is obvious that the loop is parallel and can be vectorized,
but A[0] from iteration 0 will alias with A[0] from iteration 1.
Replace `0` by `i*c` where c is a variable that can be 0 at runtime to
make the fact non-obvious to the compiler.

We had discussions about implementing "#pragma ivdep", but it's
semantics are not defined independently of the implementation. Anyway,
even with #pragma omp ivdep, a compiler is not required to vectorize
the loop.

In LLVM, runtime/partial unrolling only takes place after
vectorization, so there is less of an issue there.

Michael


Am Do., 14. Mai 2020 um 16:16 Uhr schrieb Hendrik Greving <hgreving at google.com>:
>
> This is interesting! So are you saying that loop.parallel_accesses strictly loop parallel, and says nothing about aliasing? I see, I guess we may have been "abusing" the hint and re-purposed it. But isn't llvm's vectorizer using loop.parallel_accesses to vectorize loops including vectorize memory accesses that if you ignore loop-carried dependencies, usually means effectively re-ordering the accesses? I guess this still does not imply "noalias"? What about icc/gcc's #pragma ivdep? Again here, it means no loop-carried dependencies, yet still doesn't say anything about noalias? Another way indeed would be to propagate noalias data and indeed rely on the future fix that Hal mentions above.
>
>
>
> On Thu, May 14, 2020 at 1:33 PM Michael Kruse <llvmdev at meinersbur.de> wrote:
>>
>> llvm.loop.parallel_accesses does not imply that these accesses from
>> different iterations are not aliasing. Examples where an access are
>> parallel are that the accesses are atomic or read-only from a specific
>> location.
>>
>> The LoopUnrollPass might deduce that non-atomic stores are necessarily
>> not aliasing (when not using transactional memory), but I don't think
>> we can do this for all the read accesses. Would that be sufficiently
>> useful?
>>
>> Michael
>>
>>
>> Am Do., 14. Mai 2020 um 15:11 Uhr schrieb Hendrik Greving via llvm-dev
>> <llvm-dev at lists.llvm.org>:
>> >
>> > Hi, in our backend, which is unfortunately not upstreamed, we are relying on llvm.loop.parallel_accesses metadata for certain passes like software pipelining so we can re-order instructions. Ideally, we would want the loop unroller to support the notion of the loop's parallelism in its pre-unrolled version. This probably should happen by propagating !alias.scope and !alias metadata. Is there any plan or open patch for supporting this?
>> >
>> > Simplified example:
>> >
>> > for.body:
>> > %0 = load [..]
>> >  store %0 [..]
>> > br label %for.cond, !llvm.loop !2
>> >
>> > !1 = distinct !{}
>> > !2 = distinct !{!2, !3, !4, !5, !6, !7}
>> > !3 = !{!"llvm.loop.parallel_accesses", !1}
>> > !4 = !{!"llvm.loop.vectorize.width", i32 1}
>> > !5 = !{!"llvm.loop.interleave.count", i32 1}
>> > !6 = !{!"llvm.loop.vectorize.enable", i1 true}
>> > !7 = !{!"llvm.loop.vectorize.followup_all", !8}
>> > !8 = !{!"llvm.loop.unroll.count", i32 2}
>> >
>> > (unroll by 2) =>
>> >
>> > for.body:
>> > %0 = load [..] !alias.scope !9 !noalias !11
>> > store %0 [..] !alias.scope !9 !noalias !11
>> > %1 = load [..] !alias.scope !10 !noalias !12
>> >  store %1 [..] !alias.scope !10 !noalias !12
>> > br label %for.cond, !llvm.loop !2
>> >
>> > [..]
>> >
>> > !9 = distinct !{!9, !"iteration0"}
>> > !10 = distinct !{!10, !"iteration1"}
>> > !11 = !{!10}
>> > !12 = !{!9}
>> >
>> > Thanks, Hendrik
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > llvm-dev at lists.llvm.org
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev