search for: x86_stdcall

...r()). However, calling functions that do take arguments (for example, SetLastError(unsigned int)) always crash the application due to some kind of stack corruption (Unhandled exception at 0x00000000: 0xC0000005: Access violation reading location 0x00000000.) I'm actually using the CallingConv::X86_StdCall calling convention for these external functions (F->setCallingConv(CallingConv::X86_StdCall);) and that doesn't resolve the issue. Any insight is appreciated. Please let me know if you need more details. Thanks, Vijay -------------- next part -------------- An HTML attachment was scrubbed....

...example, > SetLastError(unsigned int)) always crash the application due to some kind of > stack corruption (Unhandled exception at 0x00000000: 0xC0000005: Access > violation reading location 0x00000000.) Sounds like a calling convention issue. > I'm actually using the CallingConv::X86_StdCall calling convention for these > external functions (F->setCallingConv(CallingConv::X86_StdCall);) and that > doesn't resolve the issue. Note that you have to set the calling convention on the call. -Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: &l...

...or some calling conventions there is only one spare call clobbered register available. This is used by trampolines, so if it's also used by JIT, which is almost surely the case, that will cause trouble. Even worse, it looks like the JIT is wrong even without trampolines, because for the C and X86_StdCall conventions it is ECX that is spare, while for X86_FastCall and Fast it is EAX. Yet the JIT always uses the same hardwired code, and does not adjust according to the calling convention. So presumably it is broken for one of these sets of calling conventions. Hopefully Anton can comment on this....

...ng it on by default. No not directly. The code related to "caller/callee cleans arguments off the stack" is not controlled by the .td. It's controlled in code by the operands of CALLSEQ_END. for example in SDOperand X86TargetLowering::LowerCCCCallTo: ... if (CC == CallingConv::X86_StdCall || CC == CallingConv::Fast) { if (isVarArg) NumBytesForCalleeToPush = isSRet ? 4 : 0; else NumBytesForCalleeToPush = NumBytes; assert(!(isVarArg && CC==CallingConv::Fast) && "CallingConv::Fast does not support varargs."); } else...

Hi, We're using LLVM MCJIT on X86 platform. When calling Function::setCallingConv(CallingConv::X86_StdCall) the jitted code indeed conforms __stdcall convention (instead of default __cdecl). However applying Function::setCallingConv(CallingConv::X86_FastCall) seem does not have proper effect; jitted code is still __stdcall. Is it a bug, or am I missing something? Regards, Mikhail

I'm trying to understand the LLVM calling conventions. Coming from a Windows C++ background, I'm familiar with three calling conventions: cdecl, stdcall, and fastcall. It looks like cdecl corresponds to ccc in LLVM, but I'm not sure about the other two. Best Regards, Jon

Fellow developers, I'm parallelizing loops to be called by pthread. The thread body that I pass to pthread_create looks like define i8* @loop1({ i32*, i32* }* nest %parent_frame, i8* %arg) parent_frame is pointer to shared variables in original function 0x00007f0de11c41f0: mov (%r10),%rax 0x00007f0de11c41f3: cmpl $0x63,(%rax) 0x00007f0de11c41f6: jg 0x7f0de11c420c

On Wed, Sep 18, 2019, 2:39 PM Steven Wu <stevenwu at apple.com> wrote: > > > On Sep 18, 2019, at 10:24 AM, Steven Wu <stevenwu at apple.com> wrote: > > Hi Dwight > > Thanks for the feedback. For the issue you reported, there has been few > reviews trying to tweak the -mllvm option when using legacy LTO interfaces > (myself included) but it never got enough

Comments: CheckDAGForTailCallsAndFixThem - 1. for (SelectionDAG::allnodes_iterator BE = DAG.allnodes_begin(), + BI = prior(DAG.allnodes_end()); BI != BE; BI--) { Please use pre-decrement instead of post-decrement. 2. The function is slower than it should be. You are scanning all the nodes in the DAG twice. You should just examine DAG.getRoot() to make determine whether it's a

...uot; is not controlled by the .td. It's controlled in code > by the operands of CALLSEQ_END. Ok, that's even easier to have it be controlled by the command line option. Evan > > for example in SDOperand X86TargetLowering::LowerCCCCallTo: > ... > if (CC == CallingConv::X86_StdCall || CC == CallingConv::Fast) { > if (isVarArg) > NumBytesForCalleeToPush = isSRet ? 4 : 0; > else > NumBytesForCalleeToPush = NumBytes; > assert(!(isVarArg && CC==CallingConv::Fast) && > "CallingConv::Fast does not supp...

...ontrolled in code >> by the operands of CALLSEQ_END. > > Ok, that's even easier to have it be controlled by the command line > option. > > Evan > >> >> for example in SDOperand X86TargetLowering::LowerCCCCallTo: >> ... >> if (CC == CallingConv::X86_StdCall || CC == CallingConv::Fast) { >> if (isVarArg) >> NumBytesForCalleeToPush = isSRet ? 4 : 0; >> else >> NumBytesForCalleeToPush = NumBytes; >> assert(!(isVarArg && CC==CallingConv::Fast) && >> "Calling...

Hello, Arnold. Only quick comments, I'll try to make a full review a little bit later. > 0.)a fast calling convention (maybe use the current > CallingConv::Fast, or create a CallingConv::TailCall) > 1.) lowering of formal arguments > like for example x86_LowerCCCArguments in stdcall mode > we need to make sure that later mentioned CALL_CLOBBERED_REG is >