- User Since
- Sep 27 2019, 5:18 PM (80 w, 19 h)
Mon, Apr 5
- Remove '::' when calling static function.
- Fix bug in function merging around missing musttail.
- Add off-by-default check in verifier for swifttailcc->swifttailcc tail calls that are not marked musttail.
Thu, Mar 25
Fix codegen + add tests for methods and function pointers.
Mar 11 2021
Use musttail call instead of tail call. (This patch needs to be marked as dependent on another patch which implements proper musttail support, but that is not available yet.)
Permit swift_context and swift_indirect_result parameters for
swiftasynccall functions. (Earlier, these were restricted to
Mar 2 2021
Add null check for callee; instead of using getFunctionType() directly.
Feb 26 2021
Added checks for C++.
Feb 24 2021
Generate tail call when doing codegen for return statement.
Address review feedback; remove centralized target check for CC_SwiftAsync.
Feb 17 2021
I've updated the earlier patch https://reviews.llvm.org/D95561 to include this change, so that we don't have an in-between state where we erroneously claim that we support a bunch of targets which we don't actually support.
The TargetInfo classes are already target-architecture-specific, so it's somewhat strange for them all to funnel to a single function that then immediately switches on the target architecture.
- Remove semantic restriction of swift_async_context being only applicable to swiftasynccall.
- Update target checks to make sure we only allow supported targets.
- Update doc comment.
Feb 16 2021
Feb 12 2021
Tweak test case diff to adjust for change in previous commit.
Fix test case for debuginfo.
Feb 5 2021
Correct documentation on tail call behavior as pointed out by John.
Feb 4 2021
- Update whitespace and add documentation for swiftasynccall.
- Update commit message.
Feb 3 2021
I am planning to add more tests, figured it is better to put up the patch sooner rather than later.
Feb 2 2021
Feb 1 2021
Jan 29 2021
Could you add a short entry on swifttailcc to LangRef.rst?
Jan 27 2021
I don't get how you stack your change on top of someone else's change (the diff seems to have been created with only one commit), but this depends on https://reviews.llvm.org/D95228, which depends on https://reviews.llvm.org/D95044.
Jan 20 2021
I've fixed this by including an additional space in the string instead of using a method like outputSpaceIfNecessary; (1) that method doesn't work as it is and I think changing it for this purpose is not appropriate and (2) we probably want the space there unconditionally anyways.
Add extra space for better readability, as suggested by @compnerd.
Jan 19 2021
Closing this in favor of a Swift-side fix: https://github.com/apple/swift/pull/35488.
Jan 16 2021
The way you'd test it on the Clang side would be to just write a test case that passes such an aggregate and tests that it's passed as an i8.
Jan 15 2021
I don't know how to test this on the LLVM-side (is there a way to do it?). Here's the Swift side test which trips over right now (but is fixed with this patch) by attempting a zext from an i8 to an i1 in Swift's NativeConventionSchema::mapIntoNative.
Jan 7 2021
Going to land this as-is, will make suggested tweaks in a follow-up change.
Jan 6 2021
Dec 16 2020
Sep 1 2020
Aug 27 2020
(I'm going to wait till at least Monday to land this, in case anyone has objections or would like to suggest changes to the implementation or tests.)
Aug 26 2020
- Allow many more operations in constexpr.
- Update test to reflect use in constexpr instead of relying on implementation details.
This seems to only allow empty optionals to be constexpr. Should the non-default constructor also be constexpr?
Aug 21 2020
Jul 26 2020
Some of the changes probably don't make perfect sense in this revision because I initially started out with the whole change being one revision and then split things into commits, while trying to minimize the churn between revisions. Please also take a look at the follow-up revision D82811 and let me know if that's acceptable (less churn, less self-contained, things make sense when you look at the two together) or if you'd prefer that I make this revision more self-contained (that would create more churn in D82811).
Address review comments.
@yln could you please land the patch? I do not have commit access.
Jul 21 2020
(Could you land the patch if it looks good? I don't have commit access.)
Jul 20 2020
Jul 17 2020
Updated commit message with reviewer information and revision link.
Oh, and sorry I forgot to update the "author" field to appropriately credit you when I committed these
Thanks! It seems a bit weird that this revision now only shows the one commit under Revision contents even though the 'Commits' above shows the six commits. 🤷
Jul 16 2020
@dblaikie could you land the patch for me? I do not have bot permissions/commit privileges.
Jul 15 2020
Split up single commit into several commits (one commit per set type).
I've added some unit tests. Are these adequate/do you have any other suggestions on what I should test?
Added comments and test cases addressing fhahn's review comment.
Jul 8 2020
I don't understand the clang-tidy/clang-format complaints. I've formatted the code based on how the surrounding code is formatted.
Jul 6 2020
Thanks for the review, it's a big patch. 😅 I'm a bit busy at the moment, I will respond to the other comments later this week or sometime next week.
Jul 1 2020
Addressed review comment: replace shows -> show.
Jun 29 2020
Please review D82791: "[lit] Improve lit's output with default settings and --verbose." before reviewing this revision.
I've split this patch up into four different patches. Here is the suggested review order:
- [docs] [lit] Add a more helpful description for lit.py's -s flag.
- [NFC] [lit] Separate verbose and showOutput.
- [lit] Improve lit's output with default settings and --verbose.
Include missing commit separating verbose and showOutput.
Jun 19 2020
May 31 2020
On second thought, I'm going to update the documentation alongside the behavior change, to make sure the two are in sync.
Patch 1: Change behavior of -v. (and default and -vv behavior). Update https://llvm.org/docs/CommandGuide/lit.html as necessary.
Patch 2: Add highlighting/colored output. Update https://llvm.org/docs/CommandGuide/lit.html as necessary.
Patch 3: Rename echo_all_commands to runWithCommandOutput.
May 28 2020
Quick question: We show the command output up to and including the failing line. Should we do the same for the script part, i.e., skip the un-executed part of the script? Is it ever useful to know which script line/command would have been executed next?
@JDevlieghere, that is part of the code that is writing out the command line.