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

[John McCall]

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.