<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 - X86 calling convention issue"
href="https://bugs.llvm.org/show_bug.cgi?id=38198">38198</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>X86 calling convention issue
</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>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>new bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>eric.schweitz@pgroup.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>First, it's not clear if this is a bug or some design choice. We're seeking
some clarity on the issue.
We have a pure function that we'd like to add to LLVM as a vectorizable
intrinsic. The operation has a signature of
double opn(double, i32);
The LLVM vectorizer then creates an operation with a signature of
<2 x double> opnv(<2 x double>, <2 x i32>);
which we've added to the tables supporting the -fveclib option, etc. So far,
so good.
In GCC, one might write this vector code rather directly as (See below for a
more complete example.)
typedef double v2f64 __attribute__((vector_size (16)));
typedef int v2i32 __attribute__((vector_size (8)));
v2f64 opnv(v2f64 d, v2i32 i);
In clang (and gcc), we observe that the second argument i on x86 is declared as
"double" (as can be seen in the LLVM IR dump).
declare <2 x double> @opnv(<2 x double>, double);
The vector of 2 i32 values are coerced to double, passed in half of the xmm
register. e.g.,
xmm = <i32_1, i32_2, xxx, xxx>
However, the vectorizer prefers the signature (as shown above)
declare <2 x double> opnv(<2 x double>, <2 x i32>)
In this case, depending on the -mcpu target, etc. we can get a PSHUFD or
VPSHUFD instruction to coerce the <2 x i32> to a <2 x i64>, it seems. In these
cases we may see either of the following lane assignments.
xmm = <i32_1, i32_2, i32_2, xxx>
xmm = <i32_1, xxx, i32_2, xxx>
In the first case, the lane assignments are compatible with the clang code for
the argument i. Unfortunately, in the latter case, it appears the <2 x i32>
vector is promoted to <2 x i64> and the called routine can access the wrong
lane for the 2nd i32 value.
Here is a simple LLVM IR to reproduce the code gen.
---
target datalayout = "e-p:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
@a = global <2 x double> <double 4.0, double 5.0>
@b = global <2 x i32> <i32 27, i32 28>
define void @fun() {
L.entry:
%a = load <2 x double>, <2 x double>* @a, align 8
%b = load <2 x i32> , <2 x i32>* @b, align 8
%c = call <2 x double> @whatever (<2 x double> %a, <2 x i32> %b)
ret void
}
declare <2 x double> @whatever(<2 x double>, <2 x i32>)
---
% llc -mcpu=prescott -O2 veci32.ll
% grep xmm1 veci32.s
movq b(%rip), %xmm1 # xmm1 = mem[0],zero
pshufd $212, %xmm1, %xmm1 # xmm1 = xmm1[0,1,1,3]
% llc -mcpu=sandybridge -O2 veci32.ll
% grep xmm1 veci32.s
vpmovzxdq b(%rip), %xmm1 # xmm1 = mem[0],zero,mem[1],zero
And lastly, here is a C example using the GCC vector extension to pass a <2 x
i32>.
---
typedef int v2si __attribute__ ((vector_size (8)));
typedef double v2d __attribute__ ((vector_size (16)));
v2d do_op(v2si i);
v2d test(v2si e) {
return do_op(e);
}
---
% clang -O2 -emit-llvm -S gccvecext.c
% grep do_op gccvecext.ll
%call = tail call <2 x double> @do_op(double %e.coerce) #2
declare dso_local <2 x double> @do_op(double) local_unnamed_addr #1</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>