search for: __probestack

...; > - (future work) For LLILAC, if this attribute is present but the string > is > > 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 alloca...

...itted, even on non-Windows OSs. > - (future work) For LLILAC, if this attribute is present but the string is > 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...

...tack probes should be emitted, even on non-Windows OSs. - (future work) For LLILAC, if this attribute is present but the string is 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. On Sun, Jul 26, 2015 at 2:23 AM, John Kåre Alsaker < john.mailinglists at gmail.com> wrote: > Since David Majnemer doesn't seem overly eager to merge my patches, > let's see if we can't figure things out here. > > I noticed a string function attribute ap...

...if this attribute is present but the string >> > is >> > 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...

...e correct place to document this? For reference: http://reviews.llvm.org/D9653 http://reviews.llvm.org/D9654 http://reviews.llvm.org/D9858 On Wed, Aug 6, 2014 at 5:34 PM, John Kåre Alsaker <john.mailinglists at gmail.com> wrote: > I updated http://reviews.llvm.org/D4717 and also wrote an __probestack > implementation: > https://github.com/Zoxc/compiler-rt/compare/llvm-mirror:master...stprobe > > Which instruction would be the preferable one to probe with? I used OR since > that's what GCC/libgcc does, but I don't see why that would be better than a > write. > > &...

I updated http://reviews.llvm.org/D4717 and also wrote an __probestack implementation: https://github.com/Zoxc/compiler-rt/compare/llvm-mirror:master...stprobe Which instruction would be the preferable one to probe with? I used OR since that's what GCC/libgcc does, but I don't see why that would be better than a write. On Tue, Aug 5, 2014 at 7:34 PM, Reid K...

Would the __probestack functions be a suitable addition to compiler-rt? Does it already have __chkstk or is that provided by something else on Windows? I noticed that libgcc implemented them in cygwin.S. On Mon, Aug 4, 2014 at 9:08 PM, Philip Reames <listmail at philipreames.com> wrote: > > On 08/01/2014 0...

...t; > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits or this: > From: John Kåre Alsaker <john.mailinglists at gmail.com> > Subject: Re: [PATCH] builtins: Add __probestack support functions for x86 > To: john.mailinglists at gmail.com > Cc: llvm-commits at cs.uiuc.edu, howard.hinnant at gmail.com > Date: Tue, 19 May 2015 19:13:07 +0000 (5 hours, 39 minutes, 29 seconds ago) > Reply-To: reviews+D9858+public+2b5918b1dd4651e5 at reviews.llvm.org > > RE...

...> llvm-commits mailing list >>> llvm-commits at cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits >> >> or this: >> >>> From: John Kåre Alsaker <john.mailinglists at gmail.com> >>> Subject: Re: [PATCH] builtins: Add __probestack support functions for x86 >>> To: john.mailinglists at gmail.com >>> Cc: llvm-commits at cs.uiuc.edu, howard.hinnant at gmail.com >>> Date: Tue, 19 May 2015 19:13:07 +0000 (5 hours, 39 minutes, 29 seconds ago) >>> Reply-To: reviews+D9858+public+2b5918b1dd4651e5 a...

On Fri, Aug 1, 2014 at 11:12 PM, Philip Reames <listmail at philipreames.com> wrote: > Thanks for the explanation. I'm used to hearing the term "stack banging" > used for this mechanism, but I understand your objective. > > I believe having a general mechanism here would be valuable, but only if > the implementation doesn't make assumptions about runtime