<div dir="ltr">On Thu, Sep 5, 2013 at 1:23 PM, Erik Schnetter <span dir="ltr"><<a href="mailto:schnetter@gmail.com" target="_blank">schnetter@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I am tracking down an x86-64 code generation problem that has to do with AVX instructions. The symptom is: a function is called, and the upper half of the function argument (which is short16) is zero. This happens only when I compile code with pocl, but not when I use clang and/or llc manually.<br>

<br>
I tracked this down to the following. The call site looks like<br>
<br>
        vmovdqa 24064(%rsp), %ymm0<br>
        vmovdqa %ymm0, (%rsp)<br>
        vzeroupper<br>
        callq   __Z14convert_char16Dv16_s<br>
<br>
which passes the argument on the stack. The callee, however, begins with<br>
<br>
__Z14convert_char16Dv16_s:              ## @_Z14convert_char16Dv16_s<br>
        .cfi_startproc<br>
## BB#0:                                ## %entry<br>
        pushq   %rbp<br>
Ltmp2:<br>
        .cfi_def_cfa_offset 16<br>
Ltmp3:<br>
        .cfi_offset %rbp, -16<br>
        movq    %rsp, %rbp<br>
Ltmp4:<br>
        .cfi_def_cfa_register %rbp<br>
        vextractf128    $1, %ymm0, %xmm1<br>
<br>
which expects the argument in %ymm0. However, the vzeroupper in the caller just destroyed part of %ymm0...<br>
<br>
My question is:<br>
<br>
What decides this calling convention? I know that standard x86-64 should pass arguments in %xmm0, not %ymm0. Are there e.g. command line options, CPU attributes, or target triplets that would modify this? Or should this be filed as bug report? However, this may also be a bug in pocl as I haven't been able to reproduced this without pocl.<br>
<br></blockquote><div><br></div><div>The calling convention should be clear from the LLVM IR.  Make sure the caller and callee use the same calling convention markings.</div><div><br></div><div>You might get strange results if one translation unit has AVX and/or AVX2 enabled, and the other has it disabled: the CPU features modify the calling convention for AVX/AVX2 vectors.</div>
<div><br></div><div>-Eli </div></div><br></div></div>