[LLVMdev] Adding a stack probe function attribute

[John Kåre Alsaker]

On Tue, Jul 28, 2015 at 6:34 PM, Reid Kleckner <rnk at google.com> wrote:
> On Tue, Jul 28, 2015 at 2:25 AM, John Kåre Alsaker
> <john.mailinglists at gmail.com> wrote:
>>
>> 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.
>
>
> The difference between __probestack and __chkstk etc is that we are happy to
> call into existing interfaces that are somehow guaranteed by the
> environment. Sometimes we do invent our own in compiler-rt for obscure cases
> like i128 division, but it's rare. After years of adapting to fit
> pre-existing interfaces, we are naturally very cautious to define our own.
The code does need to go somewhere though.

> Since not everyone uses compiler-rt, I worry about a situation where people
> fight over the definition of __probestack
Wouldn't this be resolved by defining what __probestack does?

> , or where users want to override
> __probestack to call into their runtime, rather than dealing with signals.
As I said before, calls to __probestack are not guaranteed to be
emitted, so clients can't rely on it doing anything other than probing
the stack. Also clients must always deal with guard page faults. Those
will usually happen outside of __probestack, since functions with
large stack frames are rare.