@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 no hypothetical it already exists.

@rjmccall The invariant is not all swiftailcc calls need to be annotate but only calls in tail position - call followed by return.

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.

looks good to me

Looks good to me

Thank you!

Same patch. Lets restart testing. The previous failures all seemed very unrelated.

Add comment to test case.

Fix clang-tidy warnings.

Update the wording of a comment.

Use the function argument index instead of the function argument in
coro.id.async. This solves any spurious use issues.

Transfer the debug location from the suspend point to the functions called at and after the suspend point (context projection).

Yes, frontend is expected to emit a thunk that models the tail call to the function at the suspend point. This prevents code moving in between the tail call and return before coroutine splitting and allows for specifying how to perform the call (e.g pointer authentication).

Also inline the context project function used by the resume function.

I am worried about introducing unnecessary thunks that the debugger has to step through.

Semantically, it is not needed. But without inlining here this helper dispatch function thunk will remain at O0 because inlining is not run again.

Hmm, those failures also occur on other PRs. I guess we don't keep this bot clean.

No change. Retrigger tests.

Retry with clang-format. test/Other/new-pass-manager.ll passes locally

One more lint clang-tidy fix.

Fix a comment to reflect that the async context argument position is now parameterizable

Change the async function pointer's context size position

Fix Lint errors

Fix more lint errors

Address comments and lint formatting errors

Respect atomic padding.

Try to sooth clang-tidy

More clang-tidy soothing. I wish I would see its output ...

Attempt to sooth clang-tidy

Address review comments.