| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
For consistency with normal instructions and clarity when reading IR,
it's best to print the %0, %1, ... names of function arguments in
definitions.
Also modifies the parser to accept IR in that form for obvious reasons.
llvm-svn: 367755
|
| |
|
|
|
|
|
|
|
|
|
|
| |
anything.
Found by `git grep '\/\/ CHECK-[^: ]* ' clang/test/ | grep -v RUN:`.
Also tweak CodeGenCXX/arm-swiftcall.cpp to still pass now that it checks more.
Differential Revision: https://reviews.llvm.org/D58061
llvm-svn: 353744
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem with the previous logic was that there might not be any
explicit copy/move constructor declarations, e.g. if the type is
trivial and we've never type-checked a copy of it. Relying on Sema's
computation seems much more reliable.
Also, I believe Richard's recommendation is exactly the rule we use
now on the Itanium ABI, modulo the trivial_abi attribute (which this
change of course fixes our handling of in Swift).
This does mean that we have a less portable rule for deciding
indirectness for swiftcall. I would prefer it if we just applied the
Itanium rule universally under swiftcall, but in the meantime, I need
to fix this bug.
This only arises when defining functions with class-type arguments
in C++, as we do in the Swift runtime. It doesn't affect normal Swift
operation because we don't import code as C++.
llvm-svn: 328942
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D27955
llvm-svn: 290145
|
| |
|
|
| |
llvm-svn: 290121
|
| |
|
|
|
|
| |
Reviewed by abataev (in D27794)
llvm-svn: 290120
|
| |
|
|
| |
llvm-svn: 265488
|
|
|
llvm-svn: 265324
|
