search for: ___chkstk_ms

Maybe we should also change the stack probing code. I think ___chkstk_ms is used since gcc 4.6. It simplifies the prologue generation code a bit. Regards, Kai On 10.12.2013 02:18, Rafael Espíndola wrote: > Mingw switched abis with the release of gcc 4.7 > (http://gcc.gnu.org/gcc-4.7/changes.html). The main change is that now > mingw (like msvc) given thiscal...

On 11 December 2013 05:41, Kai Nacke <kai.nacke at redstar.de> wrote: > Maybe we should also change the stack probing code. I think ___chkstk_ms is > used since gcc 4.6. It simplifies the prologue generation code a bit. I just checked gcc 4.6 and looks like you are right, it uses ___chkstk_ms. LGTM. We should probably commit this first, since it is common for gcc 4.6 and newer. Cheers, Rafael

Mingw switched abis with the release of gcc 4.7 (http://gcc.gnu.org/gcc-4.7/changes.html). The main change is that now mingw (like msvc) given thiscall calling convention to methods by default. I think the last bug blocking us to support the new abi has just been fixed. The question now is how to switch. The attached patches simply switch llvm and clang to the new ABI. This is similar to what

...; empty, this can be a signal that the check must be emitted inline, either as > a sequence of stores or a loop. > > This also addresses David's concern with the hardcoded __probestack symbol > name. First of all, LLVM should be free to choose how it does stack probes, it could call ___chkstk_ms, ___chkstk_ms, __chkstk, _alloca, _chkstk, __probestack or any other stack probe function it knows about, it could unroll and inline it for smaller allocation amounts, it could inline the function entirely or it could do nothing, for platforms which does stack overflow checks in hardware. I don...

...heck must be emitted inline, > either as > > a sequence of stores or a loop. > > > > This also addresses David's concern with the hardcoded __probestack > symbol > > name. > First of all, LLVM should be free to choose how it does stack probes, > it could call ___chkstk_ms, ___chkstk_ms, __chkstk, _alloca, _chkstk, > __probestack or any other stack probe function it knows about, it > could unroll and inline it for smaller allocation amounts, it could > inline the function entirely or it could do nothing, for platforms > which does stack overflow checks in...

Hi Rafael, is more approval needed to commit? Regards, Kai On 12.12.2013 00:56, Rafael Espíndola wrote: > On 11 December 2013 05:41, Kai Nacke <kai.nacke at redstar.de> wrote: >> Maybe we should also change the stack probing code. I think ___chkstk_ms is >> used since gcc 4.6. It simplifies the prologue generation code a bit. > > I just checked gcc 4.6 and looks like you are right, it uses ___chkstk_ms. > > LGTM. We should probably commit this first, since it is common for gcc > 4.6 and newer. > > Cheers, > Rafael &...

Yeah, the function attributes section of LangRef is a reasonable place to put stuff like this: http://llvm.org/docs/LangRef.html#function-attributes I think we should add this. I also know that LLILAC needs something like this as well. I propose the following: - Add a string attribute called "stack-probe-symbol"="foo". - The presence of this attribute indicates that stack

I figured it out. I was using this implementation of __chkstk from compiler-rt: DEFINE_COMPILERRT_FUNCTION(___chkstk) push %rcx cmp $0x1000,%rax lea 16(%rsp),%rcx // rsp before calling this routine -> rcx jb 1f 2: sub $0x1000,%rcx test %rcx,(%rcx) sub $0x1000,%rax cmp $0x1000,%rax ja 2b 1:

...either as >> > a sequence of stores or a loop. >> > >> > This also addresses David's concern with the hardcoded __probestack >> > symbol >> > name. >> First of all, LLVM should be free to choose how it does stack probes, >> it could call ___chkstk_ms, ___chkstk_ms, __chkstk, _alloca, _chkstk, >> __probestack or any other stack probe function it knows about, it >> could unroll and inline it for smaller allocation amounts, it could >> inline the function entirely or it could do nothing, for platforms >> which does stack ov...

Hi, I'm trying to do a build and install on Windows 10 with Visual Studio 2015 Community Edition for the X86 and ARM targets, from the current release_40 branch. While compilation completes without error, the INSTALL target fails with the following error: 54> CMake Error at projects/compiler-rt/lib/builtins/cmake_install.cmake:34 (file): 54> file INSTALL cannot find 54>

Hi, I'd like to submit a patch to match the clang patch on the front end. http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140414/103257.html The front end doesn't need this patch to work but it's still important. This is mostly based on work done by kai from redstar.de Could I get some feedback on this? I'm not sure if the emitting of the register names will effect