[LLVMdev] Adding a stack probe function attribute

[John Kåre Alsaker]

On Tue, Jul 28, 2015 at 12:44 AM, Reid Kleckner <rnk at google.com> wrote:
> 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'll see if I can't sneak something in there.

>
> 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 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.
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't see why hardcoding __probestack is different from every other
hardcoded thing in LLVM. Furthermore since calls to it can be elided
it is not useful for clients to specify their own function, so they
would just point it to whatever the platform stack probing function
would be (replicating the ugly logic in
X86FrameLowering::emitStackProbeCall). If LLVM in the future always
inlined the call, the stack probe function would never be called and
the attribute argument is useless.

-
>
> 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 appeared in LangRef.rst, would
>> that be the 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.
>> >
>> >
>> >
>> > On Tue, Aug 5, 2014 at 7:34 PM, Reid Kleckner <rnk at google.com> wrote:
>> >>
>> >> On Tue, Aug 5, 2014 at 8:53 AM, John Kåre Alsaker
>> >> <john.mailinglists at gmail.com> wrote:
>> >>>
>> >>> 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.
>> >>
>> >>
>> >> It seems reasonable to put them in compiler-rt/lib/builtins.
>> >>
>> >> I don't think anyone is currently using compiler-rt's builtins on
>> >> Windows,
>> >> so it doesn't have __chkstk. Typically that is provided by the Cygwin,
>> >> MinGW, or MSVC C runtime.
>> >
>> >
>
>