mirror of
https://github.com/intel/llvm.git
synced 2026-01-21 12:19:23 +08:00
df282215d4
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
//===----------------------------------------------------------------------===// // C Language Family Front-end //===----------------------------------------------------------------------===// Welcome to Clang. This is a compiler front-end for the C family of languages (C, C++, Objective-C, and Objective-C++) which is built as part of the LLVM compiler infrastructure project. Unlike many other compiler frontends, Clang is useful for a number of things beyond just compiling code: we intend for Clang to be host to a number of different source-level tools. One example of this is the Clang Static Analyzer. If you're interested in more (including how to build Clang) it is best to read the relevant web sites. Here are some pointers: Information on Clang: http://clang.llvm.org/ Building and using Clang: http://clang.llvm.org/get_started.html Clang Static Analyzer: http://clang-analyzer.llvm.org/ Information on the LLVM project: http://llvm.org/ If you have questions or comments about Clang, a great place to discuss them is on the Clang development mailing list: http://lists.llvm.org/mailman/listinfo/cfe-dev If you find a bug in Clang, please file it in the LLVM bug tracker: http://llvm.org/bugs/