[LLVMdev] Adding a stack probe function attribute

[Reid Kleckner]

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.
Since not everyone uses compiler-rt, I worry about a situation where people
fight over the definition of __probestack, or where users want to override
__probestack to call into their runtime, rather than dealing with signals.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150728/28733a9b/attachment.html>