[llvm-bugs] [Bug 38198] New: X86 calling convention issue

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=38198

            Bug ID: 38198
           Summary: X86 calling convention issue
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: eric.schweitz at pgroup.com
                CC: llvm-bugs at lists.llvm.org

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180717/3a698e30/attachment.html>