[cfe-dev] [llvm-dev] RFC: Implementing the Swift calling convention in LLVM and Clang

[John McCall via cfe-dev]

> On Mar 2, 2016, at 10:48 AM, John McCall via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> On Mar 2, 2016, at 1:33 AM, Renato Golin <renato.golin at linaro.org> wrote:
>> On 2 March 2016 at 01:14, John McCall via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>> Hi, all.
>>> - We sometimes want to return more values in registers than the convention normally does, and we want to be able to use both integer and floating-point registers.  For example, we want to return a value of struct A, above, purely in registers.  For the most part, I don’t think this is a problem to layer on to an existing IR convention: C frontends will generally use explicit sret arguments when the convention requires them, and so the Swift lowering will produce result types that don’t have legal interpretations as direct results under the C convention.  But we can use a different IR convention if it’s necessary to disambiguate Swift’s desired treatment from the target's normal attempts to retroactively match the C convention.
>> 
>> Is this a back-end decision, or do you expect the front-end to tell
>> the back-end (via annotation) which parameters will be in regs? Unless
>> you also have back-end patches, I don't think the latter is going to
>> work well. For example, the ARM back-end has a huge section related to
>> passing structures in registers, which conforms to the ARM EABI, not
>> necessarily your Swift ABI.
>> 
>> Not to mention that this creates the versioning problem, where two
>> different LLVM releases can produce slightly different PCS register
>> usage (due to new features or bugs), and thus require re-compilation
>> of all libraries. This, however, is not a problem for your current
>> request, just a comment.
> 
> The frontend will not tell the backend explicitly which parameters will be
> in registers; it will just pass a bunch of independent scalar values, and
> the backend will assign them to registers or the stack as appropriate.
> 
> Our intent is to completely bypass all of the passing-structures-in-registers
> code in the backend by simply not exposing the backend to any parameters
> of aggregate type.  The frontend will turn a struct into (say) an i32, a float,
> and an i8; if the first two get passed in registers and the last gets passed
> on the stack, so be it.
> 
> The only difficulty with this plan is that, when we have multiple results, we
> don’t have a choice but to return a struct type.  To the extent that backends
> try to infer that the function actually needs to be sret, instead of just trying
> to find a way to return all the components of the struct type in appropriate
> registers, that will be sub-optimal for us.  If that’s a pervasive problem, then
> we probably just need to introduce a swift calling convention in LLVM.

Also, just a quick question.  I’m happy to continue to talk about the actual
design and implementation of LLVM IR on this point, and I’d be happy to
put out the actual patch we’re initially proposing.  Obviously, all of this code
needs to go through the normal LLVM/Clang code review processes.  But
before we continue with that, I just want to clarify one important point: assuming
that the actual implementation ends up satisfying your technical requirements,
do you have any objections to the general idea of supporting the Swift CC
in mainline LLVM?

John.