[llvm-dev] LAA behavior on Incorrect #pragma omp simd.

[Alexey Bataev via llvm-dev]

According to the OpenMP standard, The simd construct can be applied to a loop to indicate that the loop can be transformed into a SIMD loop (that is, multiple iterations of the loop can be executed concurrently using SIMD instructions). It means that the vectorization can be performed unconditionally because the user is sure that it is safe to vectorize the loop.

Best regards,
Alexey Bataev

26 июня 2019 г., в 5:54, Raja Sekhar Bhetala via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> написал(а):


Hi All,
   I have a doubt regarding the behavior of LoopAccessAnalysis on incorrect  #pragma omp simd with -fopenmp-simd flag.
How should the compiler behave if the #pragma omp simd on a loop is incorrect and can be proved by Loop Access Analysis.

Here is the sample code.

  #pragma omp simd

for (dim_t p = 0; p < m; ++p)

#pragma unroll

       for (dim_t i = 0; i < 6; ++i) {
          {
            (((r[i]).real)) += (((a[p + i * lda]).real)) * (((x[p]).real)) +
                               (((a[p + i * lda]).imag)) * (((x[p]).imag));
            (((r[i]).imag)) += (((a[p + i * lda]).imag)) * (((x[p]).real)) -
                               (((a[p + i * lda]).real)) * (((x[p]).imag));
          };
        }

The specification on this loop is incorrect as the parallel_accesses metadata indicate that there is no loop carried memory dependence, which is not true in this case.

In the default flow, LICM hoists and sinks the loads and stores of r[i]  and the loop vectorizer vectorizes this loop based on “llvm.loop.parallel_accesses” metadata.

If the hoist and sink transformation is prevented for some accesses for some reason in LICM, Loop vectorizer currently generates incorrect vector code without any warning.  Although a check is being done in LoopAccessAnalysis.cpp to detect such cases (HasDependenceInvolvingLoopInvariantAddress),  LAA does not warn if the “llvm.loop.parallel_accesses” metadata is present.

Is this expected ?
Shouldn't the compiler not Vectorize if it can prove that there is a loop carried dependence and the Vectorizer will generate an incorrect code ?
Or Should it blindly follow the user directive (without a warning) ?

It is very difficult for the user to identify the real source of the problem if the compiler vectorizes the loop silently. I agree its hard to detect incorrect specifications. But for cases, where it is easy to detect we should atleast dump a warning.

I am attaching a sample input file on which loop vectorizer generates incorrect code.
run with : opt -loop-vectorize

Thanks,
Rajasekhar

<r0.ll>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190626/28a53af6/attachment.html>