User Details
- User Since
- Dec 4 2013, 8:33 AM (442 w, 2 d)
Mar 29 2022
Mar 8 2022
Remove empty lines
Yes the LLVM verifier catches invalid uses of swifterror addresses.
Update test checks to use llvm/utils/update_test_checks.py
Feb 10 2022
lgtm
Dec 15 2021
Address review comments.
Dec 13 2021
Dec 6 2021
Nov 18 2021
Nov 16 2021
Oct 6 2021
@lxfind What do you think, is that scenario also possible with Switch lowering. Should we disable lifetime sinking and lifetime based optimization (https://reviews.llvm.org/D110949) for switch lowering until it is fixed?
@rjmccall I am not familiar with (the possible constraints of/assumptions) switch lowering but I would assume that it is broken there too (I don't have the time to investigate so I did not want to regress them needlessly).
Oct 1 2021
Sep 30 2021
Sep 21 2021
Add missing CHECKs
Sep 16 2021
Sep 8 2021
Sep 7 2021
Trying to set the dependence on https://reviews.llvm.org/D109218
LGTM
Aug 11 2021
Aug 10 2021
Aug 9 2021
Aug 5 2021
Fix clang-tidy warning - qualify auto pointer var
Jul 7 2021
Change variable name from TyAlignment to SpillAlignment
Jul 6 2021
Fix variable case and change auto to auto *
Use the compute type alignment for spilled values when spilling/restoring
Oh my. You are right I should have verified that when we spill that value though we use the right alignment. Because we don't. :(.
The spilled value from this test comes from trying to spill %vector_spill which is a value life across a suspend point. Because it has a value it has no alignment. It is misleading that we load the value from an alloca. It could also be the result of a computation. This test case crashes before the patch because we are assigning the abi alignment for the value '%vector_spill`.
Jul 1 2021
Jun 28 2021
Jun 23 2021
getSingleSuccessor call should be getSinglePredecessor
Jun 11 2021
Jun 10 2021
Jun 2 2021
May 29 2021
@efriedma It is critical for Swift that ‘swifttailcc’ function calls in tail position be executed in constant stack space. Guaranteed tail call opt was the reason why we added this convention.
May 28 2021
I guess that the 'in tail position' restriction cannot really be used by frontends because it has to predict that otherStuff() cannot be optimized away. So it would not buy us much other than a loss of clarity ...
notail is not hypothetical it already exists.
@rjmccall The invariant is not (edit: s/is/should not be imo/g) all swiftailcc calls need to be annotate but only calls in tail position - call followed by return.
May 27 2021
The whole point behind the swiftasynccc convention (swifttailcc in llvm; whose clang support we still have to upstream I think) is to use only constant stack space for an unbounded number of calls in tail call position. So this is an invariant in my opinion. If a frontend wants to opt out of that invariant in can annotate the call with nottail. The c frontend marks calls in tail position immediately followed by a return as musttail. The swift frontend uses musttail wherever appropriate.
Mar 9 2021
Mar 5 2021
Mar 3 2021
Feb 23 2021
Feb 22 2021
looks good to me
Feb 16 2021
Looks good to me
Feb 15 2021
Thank you!
Feb 12 2021
Feb 11 2021
Same patch. Lets restart testing. The previous failures all seemed very unrelated.
Feb 5 2021
Feb 4 2021
Add comment to test case.