[all-commits] [llvm/llvm-project] d7098f: De-templatify EmitCallArgs argument type checking, ...

[Reid Kleckner via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: d7098ff29c58dd08ede8314818b7de7fd2fea4cc
      https://github.com/llvm/llvm-project/commit/d7098ff29c58dd08ede8314818b7de7fd2fea4cc
  Author: Reid Kleckner <rnk at google.com>
  Date:   2020-12-09 (Wed, 09 Dec 2020)

  Changed paths:
    M clang/lib/CodeGen/CGCall.cpp
    M clang/lib/CodeGen/CGExprCXX.cpp
    M clang/lib/CodeGen/CodeGenFunction.h

  Log Message:
  -----------
  De-templatify EmitCallArgs argument type checking, NFCI

This template exists to abstract over FunctionPrototype and
ObjCMethodDecl, which have similar APIs for storing parameter types. In
place of a template, use a PointerUnion with two cases to handle this.
Hopefully this improves readability, since the type of the prototype is
easier to discover. This allows me to sink this code, which is mostly
assertions, out of the header file and into the cpp file. I can also
simplify the overloaded methods for computing isGenericMethod, and get
rid of the second EmitCallArgs overload.

Differential Revision: https://reviews.llvm.org/D92883


  Commit: df282215d497e15104ae9e182e083cdfa0bae3c2
      https://github.com/llvm/llvm-project/commit/df282215d497e15104ae9e182e083cdfa0bae3c2
  Author: Reid Kleckner <rnk at google.com>
  Date:   2020-12-09 (Wed, 09 Dec 2020)

  Changed paths:
    M clang/lib/CodeGen/CGCall.cpp
    A clang/test/CodeGenCXX/windows-x86-swiftcall.cpp

  Log Message:
  -----------
  Don't setup inalloca for swiftcc on i686-windows-msvc

Swiftcall does it's own target-independent argument type classification,
since it is not designed to be ABI compatible with anything local on the
target that isn't LLVM-based. This means it never uses inalloca.
However, we have duplicate logic for checking for inalloca parameters
that runs before call argument setup. This logic needs to know ahead of
time if inalloca will be used later, and we can't move the
CGFunctionInfo calculation earlier.

This change gets the calling convention from either the
FunctionProtoType or ObjCMethodDecl, checks if it is swift, and if so
skips the stackbase setup.

Depends on D92883.

Differential Revision: https://reviews.llvm.org/D92944


Compare: https://github.com/llvm/llvm-project/compare/199ec40e7bcc...df282215d497