On 23 Feb 2013, at 00:26, John McCall <[email protected]> wrote: > On Feb 20, 2013, at 7:52 PM, John McCall <[email protected]> wrote: >> On Feb 20, 2013, at 7:49 PM, Peter Collingbourne <[email protected]> wrote: >>> On Wed, Feb 20, 2013 at 06:30:53PM -0800, John McCall wrote: >>>> On Feb 20, 2013, at 6:24 PM, Richard Smith <[email protected]> wrote: >>>>> On Wed, Feb 20, 2013 at 6:18 PM, John McCall <[email protected]> wrote: >>>>> On Feb 20, 2013, at 6:13 PM, Peter Collingbourne <[email protected]> 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
