<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 28, 2015 at 2:25 AM, John Kåre Alsaker <span dir="ltr"><<a href="mailto:john.mailinglists@gmail.com" target="_blank">john.mailinglists@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Jul 28, 2015 at 12:44 AM, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br>
> Yeah, the function attributes section of LangRef is a reasonable place to<br>
> put stuff like this:<br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_docs_LangRef.html-23function-2Dattributes&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=9rlIyja76R2ZrXCug_HlOCMxyogXeabS4IYElEk1S-E&s=FzU3qTOwAJqYgNBlQOXwz9Mq_zEfTfu1fagnQXllfPA&e=" rel="noreferrer" target="_blank">http://llvm.org/docs/LangRef.html#function-attributes</a><br>
</span>I'll see if I can't sneak something in there.<br>
<span class=""><br>
><br>
> I think we should add this. I also know that LLILAC needs something like<br>
> this as well. I propose the following:<br>
> - Add a string attribute called "stack-probe-symbol"="foo".<br>
> - The presence of this attribute indicates that stack probes should be<br>
> emitted, even on non-Windows OSs.<br>
> - (future work) For LLILAC, if this attribute is present but the string is<br>
> empty, this can be a signal that the check must be emitted inline, either as<br>
> a sequence of stores or a loop.<br>
><br>
> This also addresses David's concern with the hardcoded __probestack symbol<br>
> name.<br>
</span>First of all, LLVM should be free to choose how it does stack probes,<br>
it could call ___chkstk_ms, ___chkstk_ms, __chkstk, _alloca, _chkstk,<br>
__probestack or any other stack probe function it knows about, it<br>
could unroll and inline it for smaller allocation amounts, it could<br>
inline the function entirely or it could do nothing, for platforms<br>
which does stack overflow checks in hardware.<br>
<br>
I don't see why hardcoding __probestack is different from every other<br>
hardcoded thing in LLVM. Furthermore since calls to it can be elided<br>
it is not useful for clients to specify their own function, so they<br>
would just point it to whatever the platform stack probing function<br>
would be (replicating the ugly logic in<br>
X86FrameLowering::emitStackProbeCall). If LLVM in the future always<br>
inlined the call, the stack probe function would never be called and<br>
the attribute argument is useless.<br></blockquote><div><br></div><div>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.</div></div></div></div>