search for: x86_stdcallcc

I think so. There have been other reports lately related to this being wrong. http://llvm.org/bugs/show_bug.cgi?id=14410 CC'ing Timur since he might know more about this. On Wed, Feb 20, 2013 at 5:27 PM, David Nadlinger <code at klickverbot.at>wrote: > On Tue, Feb 19, 2013 at 2:13 PM, Duncan Sands <baldrick at free.fr> wrote: > >> My question: Is there an easy way

...8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32" target triple = "i686-pc-linux-gnu" @.str1 = internal constant [11 x i8] c"%llu\0A%llu\0A\00" ; <[11 x i8]*> [#uses=1] declare i32 @printf(i8*, ...) define x86_stdcallcc i64 @_D3bar6retvalFZm() noinline { entry: call void asm sideeffect "movl $0, %eax ; movl $1, %edx ; ret ", "i,i,~{eax},~{edx}"(i32 255, i32 170) unreachable } define x86_stdcallcc i64 @_D3bar7retval2FZm() { entry: ret i64 730144440575 } define x86_stdca...

2013/2/21 Anton Korobeynikov <anton at korobeynikov.info>: > The patch looks incorrect. The code just needs to handle \1 properly > and clang extended to add explicit \1 to the names which does not > require mangling. I think clang already adds \01 to __stdcall names, so only the LLVM change is remaining. > I do not think that moving whole mangling to clang is a good idea, >

On Tue, Feb 19, 2013 at 2:13 PM, Duncan Sands <baldrick at free.fr> wrote: >> My question: Is there an easy way of disabling the name-mangling part >> but keep the rest of the CC that I missed? > if you use "\1" + "usual name", it will disable name mangling if you are > lucky. A leading \1 is LLVM's way of saying: leave this name alone! Seems like

...available for it. The D programming language has a feature equivalent to LLVM module level inline assembly, so we need to at least partly follow the x86 D calling convention (http://dlang.org/abi.html). Most notably, the ABI mandates that the callee cleans the stack. On the various Posixen, we use x86_stdcallcc as a basis and apply some rewrites at the IR level to make things work just well enough. However, on Windows targets this does not work because of the extra name mangling applied. My question: Is there an easy way of disabling the name-mangling part but keep the rest of the CC that I missed? Becau...

The patch looks incorrect. The code just needs to handle \1 properly and clang extended to add explicit \1 to the names which does not require mangling. I do not think that moving whole mangling to clang is a good idea, because then everyone who uses LLVM to call WinApi functions will need to mangle by hands. On Wed, Feb 20, 2013 at 11:25 PM, Timur Iskhodzhanov <timurrrr at google.com>

Anton, what do you think of David's patch with this test case? OK to commit that? On Wed, Feb 20, 2013 at 12:43 PM, Anton Korobeynikov < anton at korobeynikov.info> wrote: > The patch looks incorrect. The code just needs to handle \1 properly > and clang extended to add explicit \1 to the names which does not > require mangling. > > I do not think that moving whole

I don't remember anything other that what I've written in the bug João has mentioned. Probably something like this patch http://llvm.org/bugs/show_bug.cgi?id=14410#c6 ? 2013/2/20 João Matos <ripzonetriton at gmail.com>: > I think so. There have been other reports lately related to this being > wrong. > > http://llvm.org/bugs/show_bug.cgi?id=14410 > > CC'ing

...; <i32> [#uses=1] ret i32 %2 } define i32 @thread_call(i8* %c) nounwind { entry: %0 = bitcast i8* %c to i32 (i32, i32, double)* ; <i32 (i32, i32, double)*> [#uses=1] %1 = tail call i32 %0(i32 1, i32 1000000000, double 1.000000e+000) nounwind ; <i32> [#uses=2] %2 = tail call x86_stdcallcc i32 @GetCurrentThreadId() nounwind ; <i32> [#uses=1] %3 = tail call i32 (i8*, ...)* @printf(i8* getelementptr ([38 x i8]* @.str, i32 0, i32 0), i32 %1, i32 %2, i32 1) nounwind ; <i32> [#uses=0] ret i32 %1 } declare x86_stdcallcc i32 @GetCurrentThreadId() declare i32 @printf(i8*, ....

Hi, I'm trying to run the following module in lli on LLVM 2.6, Windows/MSVS 2008, 32 bits memory model: --- declare x86_stdcallcc i8* @GetStdHandle(i32) define i32 @main() { %handle = call i8* @GetStdHandle(i32 -11) ret i32 0 } --- (This small modules that just retrieve the handle to stdout using WIN32 API). I'm converting it to bytecode using: llvm-as.exe -f helloworldwin32.ll and running it with lli us...

Hey Jeremy, (putting the discussion back to the list.) 2013/12/8 Jeremy Lakeman <Jeremy.Lakeman at gmail.com>: > If I run your demo exe it crashes, if I re-link the dll with VS 2010 it > errors gracefully; > > runtime error R6030 > - CRT not initialized > > putchar is a c runtime function. > I'm betting that your exe doesn't initialise the runtime library?

...value types on the "CLR stack". However, I noticed that when calling external method taking those aggregate by value, they were not passed as I expected: %COLORREF = type { i8, i8, i8, i8 } declare i32 @SetLayeredWindowAttributes(i8*, %COLORREF, i8, i32) I call this function with call x86_stdcallcc (it's a Win32 function, loaded with GetProcAddress) However, checking the assembly code, it seems that the %COLORREF gets split due to the calling convention: first i8 field go through %edx, but the 3 next fields go through the stacks. I would like all of it to go through either a single 32bit...

...gt;add(createReassociatePass()); FunctionPasses->add(createGVNPass()); FunctionPasses->add(createCFGSimplificationPass()); Which does a pretty good job of cleaning up most of the messy & verbose code generated by my front end. I end up with the following bitcode; define x86_stdcallcc { i1, i32 } @fib({ i1, i32 } %arg_al_x) { entry: %"3_4" = extractvalue { i1, i32 } %arg_al_x, 0 br i1 %"3_4", label %Line15_Offset120, label %Line8_Offset38 Line8_Offset38: ; preds = %Line9_Offset52, %entry %ll_last2.0 = phi { i1, i32 } [...

...ntil the stack restore. Example ------- A single call to foo, assuming it is stdcall, would be lowered something like: %res = alloca %struct.A %base = llvm.stacksave() %arg1 = alloca %struct.A, stackbase %base %arg2 = alloca %struct.A, stackbase %base call @A_ctor(%arg1) call @A_ctor(%arg2) call x86_stdcallcc @foo(%res sret, %arg1 alloca, %arg2 alloca), stackrestore %base If control does not flow through a call or invoke with a stackrestore field, then manual calls to llvm.stackrestore must be emitted before another call or invoke can use an 'alloca' argument. The manual stack restore call end...

Hello > Is the x86_stdcallcc call convention actually supported? I found it by > digging into LLVM sources Yes. It's fully supported. > Is my initial LLVM-IR correct for invoking WIN32 API function? No. You forgot to put calling convention on the call itself. -- With best regards, Anton Korobeynikov Faculty of Mat...

Hello, Gordon. > think there is special support in the LLVM assembly language for these > two. Yes, afair - x86_stdcallcc and x86_fastcallcc > Note that fastcc / CallingConv::Fast is not fastcall. (It's actually > an alias for ccc...) No, at least on x86. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

...s. Which is to be trusted? The comment makes more sense as the variable name would effectively be blank otherwise. * Item 9 - undocumented calling conventions The following calling conventions are valid tokens but not described in the language references as of revision 223189: intel_ocl_bicc, x86_stdcallcc, x86_fastcallcc, x86_thiscallcc, kw_x86_vectorcallcc, arm_apcscc, arm_aapcscc, arm_aapcs_vfpcc, msp430_intrcc, ptx_kernel, ptx_device, spir_kernel, spir_func, x86_64_sysvcc, x86_64_win64cc, kw_ghccc Lastly I'd just like to thank the LLVM developers for all the time and hard work they'...

...t; A single call to foo, assuming it is stdcall, would be lowered something like: > > %res = alloca %struct.A > %base = llvm.stacksave() > %arg1 = alloca %struct.A, stackbase %base > %arg2 = alloca %struct.A, stackbase %base > call @A_ctor(%arg1) > call @A_ctor(%arg2) > call x86_stdcallcc @foo(%res sret, %arg1 alloca, %arg2 alloca), stackrestore %base > > If control does not flow through a call or invoke with a stackrestore field, > then manual calls to llvm.stackrestore must be emitted before another call or > invoke can use an 'alloca' argument. The manual sta...

...KEYWORD("asm", ASM_TOK); KEYWORD("sideeffect", SIDEEFFECT); KEYWORD("gc", GC); - + KEYWORD("cc", CC_TOK); KEYWORD("ccc", CCC_TOK); KEYWORD("fastcc", FASTCC_TOK); KEYWORD("coldcc", COLDCC_TOK); KEYWORD("x86_stdcallcc", X86_STDCALLCC_TOK); KEYWORD("x86_fastcallcc", X86_FASTCALLCC_TOK); - + KEYWORD("signext", SIGNEXT); KEYWORD("zeroext", ZEROEXT); KEYWORD("inreg", INREG); @@ -489,7 +491,7 @@ int LLLexer::LexIdentifier() { KEYWORD("nest", NEST...

...single call to foo, assuming it is stdcall, would be lowered something > like: > > %res = alloca %struct.A > %base = llvm.stacksave() > %arg1 = alloca %struct.A, stackbase %base > %arg2 = alloca %struct.A, stackbase %base > call @A_ctor(%arg1) > call @A_ctor(%arg2) > call x86_stdcallcc @foo(%res sret, %arg1 alloca, %arg2 alloca), > stackrestore %base > > If control does not flow through a call or invoke with a stackrestore > field, > then manual calls to llvm.stackrestore must be emitted before another call > or > invoke can use an 'alloca' argument....