Loop Vectorizer doesn't use %zmm registers on targets supporting AVX512.

[zinovy.nis]

Summary

This code

void foo(float * restrict a, float * restrict b, float * restrict c, unsigned n)
{
   for (unsigned i = 0; i < n; ++i)
       c[i] = a[i] * b[i];
}

was compiled with "-march=knl" but used only %ymm registers.

With my fix applied the generated code will use %zmm registers as it should be.

[andreadb]

Hi zinovy,

Could you please add a test for it?

You should be able to generate a test starting from your original example and building it with -emit-llvm. The resulting IR can then be used/adapted to create an 'opt' test that verifies that the body of the loop is correctly vectorized.
The idea is that your new opt test would RUN opt with flags '-mattr=+avx512f' (or -mcpu=knl) and '-loop-vectorize'.

You should be able to check that, with your change, the body of the vectorized loop now only contains fmul <16 x float> instructions. Before your change, it was producing instead a sequence of fmul <8 x float>.

I hope this make sense :-)

Andrea.

[zinovy.nis]

Thanks. Done. Plz see my update.

2014-03-14 18:21 GMT+04:00 Andrea Di Biagio <[e-mail]>:

Hi zinovy,

Could you please add a test for it?

You should be able to generate a test starting from your original

example and building it with -emit-llvm. The resulting IR can then be
used/adapted to create an 'opt' test that verifies that the body of the
loop is correctly vectorized.

The idea is that your new opt test would RUN opt with flags

'-mattr=+avx512f' (or -mcpu=knl) and '-loop-vectorize'.

You should be able to check that, with your change, the body of the

vectorized loop now only contains fmul <16 x float> instructions. Before
your change, it was producing instead a sequence of fmul <8 x float>.

I hope this make sense :-)

Andrea.

http://llvm-reviews.chandlerc.com/D3078

[aschwaighofer]

Curious, did you test whether the cost model works reasonably well across the test-suite with this turned on? Are there any/many major regressions with this patch applied vs without on an avx512 architecture?

Thanks,
Arnold

test/CodeGen/X86/avx512-vectorizer.ll

9

You could remove the no capture and readonly attributes. They are not needed for this test case.

I am also surprised that llvm accepts dangling function attributes ("#0”) but it does :).

[zinovy.nis]

I have no real avx512 architecture at hands.
But I believe that using wider vectors is better than using shorter ones in
this case.
BTW, the KNL cost model in LLVM was taken from the Haswell cost model (see
TODOs in x86.td), so it can't be very accurate for KNL.

-----Исходное сообщение-----
From: Arnold Schwaighofer
Sent: Friday, March 14, 2014 8:08 PM
To: [e-mail] ; [e-mail] ;
[e-mail] ; [e-mail] ; [e-mail]
Cc: [e-mail] ; [e-mail] ;
[e-mail]
Subject: Re: [PATCH] Loop Vectorizer doesn't use %zmm registers on targets
supporting AVX512.

Curious, did you test whether the cost model works reasonably well across

the test-suite with this turned on? Are there any/many major regressions
with this patch applied vs without on an avx512 architecture?

Thanks,
Arnold

Comment at: test/CodeGen/X86/avx512-vectorizer.ll:8
@@ +7,3 @@
+
+define void @foo(float* noalias nocapture readonly %a, float* noalias
nocapture readonly %b, float* noalias nocapture %c, i32 %n) #0 {

+entry:

You could remove the no capture and readonly attributes. They are not needed
for this test case.

I am also surprised that llvm accepts dangling function attributes ("#0”)
but it does :).

http://llvm-reviews.chandlerc.com/D3078

[zinovy.nis]

"nocapture" & "readonly" attributes removed from the test.

[andreadb]

Hi Zinovy,

A minor comment:
your new test should be probably moved to 'test/Transforms/LoopVectorize/X86' since it is clearly testing the loop vectorizer behavior on a specific x86 target.

test/CodeGen/X86/avx512-vectorizer.ll

8

You can remove the '#0' from the signature of @foo since it is not used.

[zinovy.nis]

The test file was moved to 'test/Transforms/LoopVectorize/X86'.

[zinovy.nis]

Fix number of vector registers for 64-bit mode in KNL to 32 instead of 16.

[zinovy.nis]

Was commited in rL212634 by Adam Nemet.

lib/Target/X86/X86TargetTransformInfo.cpp

unsigned X86TTI::getNumberOfRegisters(bool Vector) const {
 
   if (ST->is64Bit())
     return 16;
   return 8;
 }
 
 unsigned X86TTI::getRegisterBitWidth(bool Vector) const {
   if (Vector) {
+    if (ST->hasAVX512()) return 512;
     if (ST->hasAVX()) return 256;
     if (ST->hasSSE1()) return 128;
     return 0;
   }
 
   if (ST->is64Bit())
     return 64;
   return 32;

test/CodeGen/X86/avx512-vectorizer.ll

+; RUN: opt -mattr=+avx512f -loop-vectorize -S < %s | FileCheck %s
+; CHECK: <16 x float>
+; CHECK-NOT: <8 x float>
+
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+define void @foo(float* noalias %a, float* noalias %b, float* noalias %c, i32 %n) #0 {
+entry:
+  br label %for.body
+
+for.body:
+  %indvars.iv = phi i64 [ 0, %entry ], [ %indvars.iv.next, %for.body ]
+  %arrayidx = getelementptr inbounds float* %a, i64 %indvars.iv
+  %0 = load float* %arrayidx, align 4
+  %arrayidx2 = getelementptr inbounds float* %b, i64 %indvars.iv
+  %1 = load float* %arrayidx2, align 4
+  %mul = fmul fast float %0, %1
+  %arrayidx4 = getelementptr inbounds float* %c, i64 %indvars.iv
+  store float %mul, float* %arrayidx4, align 4
+  %indvars.iv.next = add nuw nsw i64 %indvars.iv, 1
+  %exitcond = icmp eq i64 %indvars.iv.next, 1024
+  br i1 %exitcond, label %for.end, label %for.body
+
+for.end:
+  ret void
+}