[llvm-bugs] [Bug 43208] New: Struct return does not match Windows X64 stack convention.

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Sep 3 09:23:43 PDT 2019


            Bug ID: 43208
           Summary: Struct return does not match Windows X64 stack
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: LChrisman at Lumina.com
                CC: craig.topper at gmail.com, llvm-bugs at lists.llvm.org,
                    llvm-dev at redking.me.uk, spatel+llvm at rotateright.com

As I understand it, the Microsoft Win x64 calling convention returns a struct
that exceeds 64 bits as if it were the 1st parameter of the function. I.e.,
caller sets RCX to point to memory for the return struct (usually on caller's
stack), then callee sets RAX to same.

This is not the convention that I see being used when running LLVM on windows.
This function:

%MyStruct = type { i16, i64 }

define common %MyStruct @ret_struct() {
  ret %MyStruct { i16 13, i64 23 }

compiles to:

mov         ax,0Dh  
mov         edx,17h  

Then a call to the function from VC++ crashes.  I would expect to see something
more like:

mov word ptr [ecx],0Dh
mov dword ptr [rcx+8],17h
mov rax,rcx

When I look at the code generated by VC++ for the function:

MyStruct G()
   return MyStruct{13,23};

I see it doing basically this.

Because of the calling convention mismatch, my call to the LLVM-compiled
function crashes, i.e.:

    auto F = (MyStruct(*)()) ExitOnErr(jit->lookup("ret_struct")).getAddress();
    MyStruct s = F();   // crash

I notice that llc does the same thing for this example. E.g.: given a file "try
call conv.ll" containing:

%MyStruct = type { i16, i64 }

define %MyStruct @ret_struct() {
  ret %MyStruct { i16 13, i64 23 }

Then the command:
> llc "try call conv.ll" -o -

        .def     ret_struct;
        .scl    2;
        .type   32;
        .globl  ret_struct
        .align  16, 0x90
ret_struct:                             # @ret_struct
# BB#0:                                 # %begin
        movw    $13, %ax
        movl    $23, %edx

However, I also find an inconsistency between llc and the libraries. When I
change the example to

%MyStruct = type { i16, i8, i64 }

define %MyStruct @ret_struct() {
  ret %MyStruct { i16 13, i8 0, i64 23 }

(The i8 is in the padding area, so this doesn't change the struct size) In this
case, llc uses the window x64 return convention (good):

        .def     ret_struct;
        .scl    2;
        .type   32;
        .globl  ret_struct
        .align  16, 0x90
ret_struct:                             # @ret_struct
# BB#0:                                 # %begin
        movq    $23, 8(%rcx)
        movb    $0, 2(%rcx)
        movw    $13, (%rcx)

But, when I make this same change in the C++ code, it still returns the struct
in registers, not using the Microsoft x64 convention.

In C++, setting the calling convention for the function to Win64 does not
change the code generated in either example.

Here is the C++ code. Compiled on VC++ 2017. Same on both Win10 & Win7.

#include "llvm/Bitcode/BitcodeWriter.h"
#include "llvm/IR/BasicBlock.h"
#include "llvm/IR/Constants.h"
#include "llvm/IR/DerivedTypes.h"
#include "llvm/IR/Function.h"
#include "llvm/IR/InstrTypes.h"
#include "llvm/IR/Instruction.h"
#include "llvm/IR/Instructions.h"
#include "llvm/IR/LLVMContext.h"
#include "llvm/IR/Module.h"
#include "llvm/IR/Type.h"
#include "llvm/Support/raw_ostream.h"
#include "llvm/ExecutionEngine/Orc/LLJIT.h"
#include "llvm/Support//TargetSelect.h"
#include "llvm/IR/IRBuilder.h"
#include <iostream>

using namespace llvm;
using namespace llvm::orc;
using std::cout;
using std::endl;
using std::unique_ptr;
using std::make_unique;

ExitOnError ExitOnErr;

struct MyStruct {
        uint16_t n1_;
        uint64_t n2_;

ThreadSafeModule MakeM()
        auto pCtx = make_unique<LLVMContext>();
        auto& ctx = *pCtx;
        auto pM = make_unique<Module>("My_module",ctx);
        auto& M = *pM;

        auto myStruct = StructType::create(ctx,
                {       Type::getInt16Ty(ctx),
        FunctionType* proto = FunctionType::get(myStruct,false);
        Function* fn =
        BasicBlock* BB = BasicBlock::Create(ctx,"begin",fn);
        IRBuilder<> builder(BB);
        //Value* ms = builder.CreateAlloca(myStruct,nullptr,"ms");
        auto ms = ConstantStruct::get(myStruct,
                {       ConstantInt::get(ctx,APInt(16,13,true)), 
                } );
        cout << "The IR is:\n";
        outs() << M;
        cout << endl;

        return ThreadSafeModule(std::move(pM),std::move(pCtx));

static MyStruct G()
        return MyStruct{88,77};

void Test_Call_Convention()
        auto jit = ExitOnErr(LLJITBuilder().create());
        auto M = MakeM();
        ExitOnError ExitOnErr;
        auto F = (MyStruct(*)())

        auto g = G;
        MyStruct s1 = g();

        MyStruct s = F();
        std::cout << "MyStruct{" << s.n1_ << ',' << s.n2_ << "}\n";


int main()

        return 0;

For what it is worth, I traced down to
llvm\lib\CodeGen\SelectionDAG\FunctionLoweringInfo.cpp line 96:

  CanLowerReturn =
      TLI->CanLowerReturn(CC, *MF, Fn->isVarArg(), Outs, Fn->getContext());

When I put a breakpoint after this, then change the value to False in the
debugger, it produces the expected code. This routine calls into:

bool X86TargetLowering::CanLowerReturn(...)

in llvm\lib\Target\X86\X86ISelLowering.cpp

I can't help but feel that I am making a fundamental mistake somewhere, since
this seems so blatant. Related bugs like 39251, 16168, 37760 and 42439 seem to
be far more subtle. If I'm missing something, accept my apologies and let me
know. If I am not wrong, seems like a release blocker, right?

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/20190903/f64c4d32/attachment.html>

More information about the llvm-bugs mailing list