[LLVMdev] [PATCH] Add support for coldcc to clang

[Richard Osborne]

On 23 Feb 2013, at 00:26, John McCall <rjmccall at apple.com> wrote:

> On Feb 20, 2013, at 7:52 PM, John McCall <rjmccall at apple.com> wrote:
>> On Feb 20, 2013, at 7:49 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
>>> On Wed, Feb 20, 2013 at 06:30:53PM -0800, John McCall wrote:
>>>> On Feb 20, 2013, at 6:24 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>>>>> On Wed, Feb 20, 2013 at 6:18 PM, John McCall <rjmccall at apple.com> wrote:
>>>>> On Feb 20, 2013, at 6:13 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
>>>>>> http://llvm-reviews.chandlerc.com/D443
>>>>> 
>>>>> Are you sure we actually *want* to expose this to users?
>>>>> 
>>>>> I would like to mark the UBSan runtime handler functions as __attribute__((coldcc)), and I think that would make sense for other sanitizers too.
>>>> 
>>>> Are we now willing to commit to a fixed ABI for coldcc?  I thought we hadn't been.
>>> 
>>> Implementing __attribute__((coldcc)) does not necessarily imply fixing
>>> the ABI, provided that we document the attribute as such.  It should
>>> be safe to use in compiler_rt once we modify its build system to use the
>>> just-built clang.
>> 
>> I agree that we could certainly expose a calling convention with zero
>> binary-compatibility guarantees.  I don't know if that would work for what
>> Richard wants, though.  Notably, you can't stick that sort of thing in a
>> library that you haven't rev-locked to the compiler.
> 
> CC'ing llvmdev.
> 
> Okay, so per recent traffic on this thread, it sounds like this is not currently
> required for the sanitizers.  That leaves a few questions open:
> 
> 1.  Do we still care about exposing this CC to user code at all?
> 2.  What ABI guarantees exactly are we making with this convention?
>  - Is it worth asking LLVM to commit to a particular convention?
>  - If not, what exactly is LLVM willing to guarantee?
>    - Only calls to module-internal functions?
>    - Calls to functions whose implementation is guaranteed to be compiled
>      with this exact version of the compiler?
>    - Some coarser degree of stability?
> 3.  If we do publish this, what name do we use?
>  - Does not putting LLVM in the name imply that this is some portable thing?
>  - Should we put something like "unstable" in the name to encourage users
>    to think twice about using this casually?
> 4.  Is there a good reason to publicize only coldcc and not fastcc as well?
> 5.  IIRC, coldcc is not just a calling convention — it's also interpreted as a hint
>  that the code path performing that call is not frequently taken.  Is that
>  something we should document?
> 
> Note that *any* sort of cross-module ABI guarantee can bite us — .a library
> distribution is not uncommon (indeed, on iOS, it's the only supported form
> of user library).
> 
> John.

I'd certainly find it useful to expose the fastcc calling convention via an attribute.

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.

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).

[1] https://github.com/rlsosborne/tool_axe