Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MS ABI] Bad interaction between inalloca call and expanded memcpy #19386

Closed
zmodem opened this issue Mar 1, 2014 · 4 comments
Closed

[MS ABI] Bad interaction between inalloca call and expanded memcpy #19386

zmodem opened this issue Mar 1, 2014 · 4 comments
Assignees
Labels
bugzilla Issues migrated from bugzilla clang Clang issues not falling into any other category

Comments

@zmodem
Copy link
Collaborator

zmodem commented Mar 1, 2014

Bugzilla Link 19012
Resolution FIXED
Resolved on Aug 29, 2014 15:51
Version unspecified
OS Windows NT
Blocks #12849 #19261
CC @rnk

Extended Description

The following program crashes when built with clang-cl:

(If the #if 1 is changed to #if 0, it doesn't crash. For some reason that causes us not to expand the memcpy.)

struct Ptr {
~Ptr() {}
int *ptr;
};

#if 1
struct Arr {
struct {
struct {
char name[54];
} mailbox;
int texture_target;
int sync_point;
} mailbox_holder;
void *shared_memory;
struct shared_memory_size {
int width;
int height;
} memory_size;
};
#else
struct Arr {
char x[76];
};
#endif

void f(Ptr) {}

void g(Arr *a, Arr *b, Ptr *p) {
*a = *b; // memcpy, possibly expanded to rep movs, clobbering esi
f(*p); // inalloca call, causing chkstk, not expecting clobbered esi
};

int main() {
Ptr p = {};
Arr a = {}, b = {};
g(&a, &b, &p);
return 0;
}

(Reduced from Chromium's cc::CopyOutputResult::TakeTexture.)

@zmodem
Copy link
Collaborator Author

zmodem commented Mar 1, 2014

assigned to @zmodem

@zmodem
Copy link
Collaborator Author

zmodem commented Mar 3, 2014

Slightly reduced:

$ llc -mcpu=pentium4 a.ll -o -

a.ll:

target datalayout = "e-m:w-p:32:32-i64:64-f80:32-n8:16:32-S32"
target triple = "i686-pc-win32"

%struct.Ptr = type { i32* }
%struct.Arr = type { %struct.anon, i8*, %"struct.Arr::shared_memory_size" }
%struct.anon = type { %struct.anon.0, i32, i32 }
%struct.anon.0 = type { [54 x i8] }
%"struct.Arr::shared_memory_size" = type { i32, i32 }

declare void @​llvm.memcpy.p0i8.p0i8.i32(i8* nocapture, i8* nocapture readonly, i32, i32, i1)
declare i8* @​llvm.stacksave()
declare void @​llvm.stackrestore(i8*)
declare void @​f(<{ %struct.Ptr }>* inalloca) #​0

define void @​g(%struct.Arr* %a, %struct.Arr* %b, %struct.Ptr* %p) #​0 {
entry:
%inalloca.spmem = alloca i8*
%aptr = bitcast %struct.Arr* %a to i8*
%bptr = bitcast %struct.Arr* %b to i8*
%pptr = bitcast %struct.Ptr* %p to i8*
call void @​llvm.memcpy.p0i8.p0i8.i32(i8* %aptr, i8* %bptr, i32 76, i32 4, i1 false)
%inalloca.save = call i8* @​llvm.stacksave()
%argmem = alloca <{ %struct.Ptr }>, inalloca
store i8* %inalloca.save, i8** %inalloca.spmem
%gep = getelementptr inbounds <{ %struct.Ptr }>* %argmem, i32 0, i32 0
%gepptr = bitcast %struct.Ptr* %gep to i8*
call void @​llvm.memcpy.p0i8.p0i8.i32(i8* %gepptr, i8* %pptr, i32 4, i32 4, i1 false)
call void @​f(<{ %struct.Ptr }>* inalloca %argmem)
call void @​llvm.stackrestore(i8* %inalloca.save)
ret void
}

@zmodem
Copy link
Collaborator Author

zmodem commented Mar 5, 2014

Should be fixed with r202930.

@rnk
Copy link
Collaborator

rnk commented Aug 29, 2014

Hopefully fixed harder in r216775.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 9, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla clang Clang issues not falling into any other category
Projects
None yet
Development

No branches or pull requests

2 participants