Include test case where the llvm.type.checked.load.relative intrinsic is
expanded to compute the pointer underlying the relative pointer value.

Run clang-format.

This looks good to me. Can you rebase your patch so that it applies on top of github.com:apple/llvm-project.git main?

Simplify logic whether a frame access needs dynamic alignment.

Add asserts that the dynamic alignment frame information when constructing the
frame matches the alloca.

Address comment.

Remove empty lines

Yes the LLVM verifier catches invalid uses of swifterror addresses.

Update test checks to use llvm/utils/update_test_checks.py

lgtm

Address review comments.

@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).

Add missing CHECKs

Trying to set the dependence on https://reviews.llvm.org/D109218

LGTM

Fix clang-tidy warning - qualify auto pointer var

Change variable name from TyAlignment to SpillAlignment

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`.

getSingleSuccessor call should be getSinglePredecessor

@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.

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.