<br><br><div class="gmail_quote">On Sat, Feb 23, 2013 at 3:53 AM, Richard Osborne <span dir="ltr"><<a href="mailto:richard@xmos.com" target="_blank">richard@xmos.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><br>
On 23 Feb 2013, at 00:26, John McCall <<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>> wrote:<br>
<br>
> On Feb 20, 2013, at 7:52 PM, John McCall <<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>> wrote:<br>
>> On Feb 20, 2013, at 7:49 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>> wrote:<br>
>>> On Wed, Feb 20, 2013 at 06:30:53PM -0800, John McCall wrote:<br>
>>>> On Feb 20, 2013, at 6:24 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:<br>
>>>>> On Wed, Feb 20, 2013 at 6:18 PM, John McCall <<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>> wrote:<br>
>>>>> On Feb 20, 2013, at 6:13 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>> wrote:<br>
>>>>>> <a href="http://llvm-reviews.chandlerc.com/D443" target="_blank">http://llvm-reviews.chandlerc.com/D443</a><br>
>>>>><br>
>>>>> Are you sure we actually *want* to expose this to users?<br>
>>>>><br>
>>>>> I would like to mark the UBSan runtime handler functions as __attribute__((coldcc)), and I think that would make sense for other sanitizers too.<br>
>>>><br>
>>>> Are we now willing to commit to a fixed ABI for coldcc? I thought we hadn't been.<br>
>>><br>
>>> Implementing __attribute__((coldcc)) does not necessarily imply fixing<br>
>>> the ABI, provided that we document the attribute as such. It should<br>
>>> be safe to use in compiler_rt once we modify its build system to use the<br>
>>> just-built clang.<br>
>><br>
>> I agree that we could certainly expose a calling convention with zero<br>
>> binary-compatibility guarantees. I don't know if that would work for what<br>
>> Richard wants, though. Notably, you can't stick that sort of thing in a<br>
>> library that you haven't rev-locked to the compiler.<br>
><br>
> CC'ing llvmdev.<br>
><br>
> Okay, so per recent traffic on this thread, it sounds like this is not currently<br>
> required for the sanitizers. That leaves a few questions open:<br>
><br>
> 1. Do we still care about exposing this CC to user code at all?<br>
> 2. What ABI guarantees exactly are we making with this convention?<br>
> - Is it worth asking LLVM to commit to a particular convention?<br>
> - If not, what exactly is LLVM willing to guarantee?<br>
> - Only calls to module-internal functions?<br>
> - Calls to functions whose implementation is guaranteed to be compiled<br>
> with this exact version of the compiler?<br>
> - Some coarser degree of stability?<br>
> 3. If we do publish this, what name do we use?<br>
> - Does not putting LLVM in the name imply that this is some portable thing?<br>
> - Should we put something like "unstable" in the name to encourage users<br>
> to think twice about using this casually?<br>
> 4. Is there a good reason to publicize only coldcc and not fastcc as well?<br>
> 5. IIRC, coldcc is not just a calling convention — it's also interpreted as a hint<br>
> that the code path performing that call is not frequently taken. Is that<br>
> something we should document?<br>
><br>
> Note that *any* sort of cross-module ABI guarantee can bite us — .a library<br>
> distribution is not uncommon (indeed, on iOS, it's the only supported form<br>
> of user library).<br>
><br>
> John.<br>
<br>
</div></div>I'd certainly find it useful to expose the fastcc calling convention via an attribute.<br>
<br>
I have project[1] where I generate functions that are JIT compiled with LLVM. I mark all these functions with the "fastcc" calling convention to guarantee efficient tail calls between them. At the moment I must also generate thunks so these functions can be called from non JIT'd code. With the the fastcc attribute I wouldn't need the thunks and I could call JIT'd functions directly after casting them to the right type. I could see a coldcc attribute being useful for similar reasons.<br>
</blockquote><div><br></div><div>LLVM's overloading of "fastcc" for guaranteed tail calls is kind of a hack. For languages which need it, guaranteed tail calls aren't just an optimization (make this run "fast"), they're of course *required* for correctness. Consequently, overloading fastcc to cover both of these purposes means that both are unnecessarily constrained by the other's problems. Guaranteed tail calls don't need fastcc's ABI volatility, while fastcc doesn't need guaranteed tail call's reservation of an extra register for the callee in some cases. It's my impression that LLVM has lumped these two things together because it didn't view them as important enough to have separate calling conventions. Perhaps it's now a good time to re-evaluate that decision.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In regards to naming fastcc is easy to confuse with X86 fastcall calling convention. I think it would be sensible to add LLVM to the name when exposing it to users as this clearly implies that the calling convention is a non-portable, LLVM specific thing (e.g. llvm_fastcc).<br>
</blockquote><div><br></div><div>It's not an LLVM-specific thing. It's a specific-version-of-LLVM-specific thing, because each version of LLVM could be different. It's neither forward nor backward compatible. This is not a normal thing for C compilers to expose to users.</div>
<div><br></div><div>Dan</div><div><br></div></div>