[PATCH] D34474: [RFC] [AArch64] Add a win64 specific aarch64 calling convention, for va_list handling

[Martin Storsjö via Phabricator via llvm-commits]

mstorsjo added a comment.

In https://reviews.llvm.org/D34474#799086, @compnerd wrote:

> I'm still not sure I understand why we need the different CC when X86_64 is able to handle both the SysV and the MS style VAArg lowering via the ABI::LowerVAArg switching between the two.  I feel that we should follow a similar approach here.


This does in fact use the exat same approach as on x86_64. It's not an issue with LowerVAARG (where the handling of the MS style can be encapsulated on the clang level so there's no need for any support for that on the LLVM level at all), but the issue is with LowerVASTART. And for LowerVASTART, the handling is identical to the one on x86_64. The key parts from `X86TargetLowering::LowerVASTART` in `lib/Target/X86/X86ISelLowering.cpp`:

  SDValue X86TargetLowering::LowerVASTART(SDValue Op, SelectionDAG &DAG) const {
    if (!Subtarget.is64Bit() ||   
        Subtarget.isCallingConvWin64(MF.getFunction()->getCallingConv())) {

And `isCallingConvWin64` contains this (redacted):

  bool isCallingConvWin64(CallingConv::ID CC) const {
    switch (CC) {
    // On Win64, all these conventions just use the default convention.
    case CallingConv::C:
      return isTargetWin64();
    // This convention allows using the Win64 convention on other targets.
    case CallingConv::X86_64_Win64:
      return true;
    // This convention allows using the SysV convention on Windows targets.
    case CallingConv::X86_64_SysV:
      return false;
    // Otherwise, who knows what this is.
    default:
      return false;
    } 

As long as the windows ABI only should be used while targeting windows, we indeed don't need a separate calling convention exposed in the IR. But in order to be able to implement wine, we need to be able to signal that this particular function uses a convention different from the default of the current target triplet.


https://reviews.llvm.org/D34474