[LLVMbugs] [Bug 23083] New: Function multi-versioning miscompiles subtarget-dependent calling conventions

[bugzilla-daemon at llvm.org]

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

            Bug ID: 23083
           Summary: Function multi-versioning miscompiles
                    subtarget-dependent calling conventions
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: michael.m.kuperstein at intel.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Given this IR input:

target datalayout = "e-m:w-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-windows-msvc"

define <8 x float> @foo(<8 x float> %a, <8 x float> %b) #0 {
entry:
  %ret = call x86_vectorcallcc <8 x float> @bar(<8 x float> %a, <8 x float> %b)
  ret <8 x float> %ret
}

define x86_vectorcallcc <8 x float> @bar(<8 x float> %a, <8 x float> %b) #1 {
  %add = fadd <8 x float> %a, %b
  ret <8 x float> %add
}

attributes #0 = { nounwind "target-features"="-avx"}
attributes #1 = { nounwind "target-features"="+avx" }

We currently get:

foo:                                    # @foo
# BB#0:                                 # %entry
        subq    $40, %rsp
        movaps  (%rcx), %xmm0
        movaps  (%rdx), %xmm1
        movaps  (%r8), %xmm2
        movaps  (%r9), %xmm3
        callq   bar@@64
        addq    $40, %rsp
        retq

        .def     bar@@64;
        .scl    2;
        .type   32;
        .endef
        .globl  bar@@64
        .align  16, 0x90
bar@@64:                                # @bar
# BB#0:
        vaddps  %ymm1, %ymm0, %ymm0
        retq

The caller passes <8 x float> in 2 xmms, while the callee expects a single ymm.

Note that this is not restricted to passing in-register. When passing on the
stack(removing the vectorcall CC) we get a similar - albeit possibly more
"fixable" - miscompile:

foo:                                    # @foo
# BB#0:                                 # %entry
        subq    $104, %rsp
        movaps  (%r9), %xmm0
        movaps  (%r8), %xmm1
        movaps  (%rdx), %xmm2
        movaps  (%rcx), %xmm3
        movaps  %xmm3, 80(%rsp)
        movaps  %xmm2, 64(%rsp)
        movaps  %xmm1, 48(%rsp)
        movaps  %xmm0, 32(%rsp)
        leaq    80(%rsp), %rcx
        leaq    64(%rsp), %rdx
        leaq    48(%rsp), %r8
        leaq    32(%rsp), %r9
        callq   bar
        addq    $104, %rsp
        retq

        .def     bar;
        .scl    2;
        .type   32;
        .endef
        .globl  bar
        .align  16, 0x90
bar:                                    # @bar
# BB#0:
        vmovaps (%rcx), %ymm0
        vaddps  (%rdx), %ymm0, %ymm0
        retq

-- 
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/20150331/4922eb39/attachment.html>