<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Illegal vectorization of a loop with a recurrence with Skylake, KNL"
href="https://bugs.llvm.org/show_bug.cgi?id=41732">41732</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Illegal vectorization of a loop with a recurrence with Skylake, KNL
</td>
</tr>
<tr>
<th>Product</th>
<td>new-bugs
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>new bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>hideki.saito@intel.com
</td>
</tr>
<tr>
<th>Reporter</th>
<td>rscottmanley@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>craig.topper@gmail.com, hfinkel@anl.gov, htmldeveloper@gmail.com, llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>The test case below is derived from an HPC benchmark. llvm is illegaly
vectorizing the loop in function one() despite an obvious recurrence.
Curiously, when function two() is commented out, llvm correctly determines it
is unsafe to vectorize. If you inhibit inlining of one() it also prevents
vectorization.
I did some trace debugging and found in the good version,
DepChecker-areDepsSafe() returns false, but true in the bad version.
// bad version
clang -S -O2 -Rpass=loop-vectorize test.c -march=skylake-avx512
test.c:6:3: remark: vectorized loop (vectorization width: 16, interleaved
count: 1) [-Rpass=loop-vectorize]
do {
^
// good version
clang -S -O2 -Rpass=loop-vectorize -Rpass-missed=loop-vectorize test.c
-march=skylake-avx512 -DNO_TWO
test.c:6:3: remark: loop not vectorized [-Rpass-missed=loop-vectorize]
do {
Note: The problem exists on other targets, but the loops are incidentally
correct because they are not considered profitable. For instance, with
-march=broadwell (which does not have hw scatter):
LV: Loop cost is 8
LV: Interleaving to reduce branch cost.
LV: Vectorization is possible but not beneficial.
LV: Interleaving is not beneficial.
but with -march=knl, we see vectorization as well.
Test case:
static void __attribute__ ((always_inline)) one(
const int *restrict in, const int *const end,
const unsigned shift, int *const restrict index,
int *const restrict out)
{
do {
int a_idx = *in>>shift;
int b_idx = index[a_idx];
out[b_idx] = *in; // <-- reccurence as index[a_idx] can be the
index[a_idx]++; // same and incremented within the vector
} while(++in!=end); // which leads to incorrect results
}
#ifndef NO_TWO
static void __attribute__ ((noinline)) two(
const int *restrict in, const int *const end,
const unsigned shift, int *const restrict index,
int *const restrict out)
{
do out[index[(*in>>shift)]++]=*in; while(++in!=end);
}
#endif
void parent(
int digits, int n, int *restrict work, int * restrict idx,
int *restrict shift, int **restrict indices)
{
int *in = work;
int *dst = work+n;
int d;
for(d=1;d!=digits-1;++d) {
int *t;
one(in,in+n,shift[d],indices[d],dst);
t=in,in=dst,dst=t;
}
#ifndef NO_TWO
two(in,in+n,shift[d],indices[d],idx);
#endif
}</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>