[PATCH] D95044: IR+AArch64: add `swiftasync` function parameter attribute

[Tim Northover via Phabricator via llvm-commits]

t.p.northover added a comment.

Thanks for the questions. I'm quite fuzzy on the Swift side of this I'm afraid,  so take my replies with a pinch of salt.

> Do you happen to have a pointer to some more documentation about this new Swift feature?

Most of the ABI-specific things are unfortunately on internal documents. The Swift proposals exist and I'll put links here, but kind of understandably they focus on the implications for Swift itself. But with that in mind, there's:

https://github.com/DougGregor/swift-evolution/blob/async-await/proposals/nnnn-async-await.md
https://github.com/DougGregor/swift-evolution/blob/structured-concurrency/proposals/nnnn-structured-concurrency.md
https://github.com/DougGregor/swift-evolution/blob/actors/proposals/nnnn-actors.md

I think that third one about Actors is probably most significant here, as far as I understand the idea is that the context will store the current Actor, the current Task, and an asynchronous backtrace structure. I'm afraid I don't yet know what form that will take, even from our own pages.

> I wonder if any features from other languages could also map to this IR/backend implementation? E.g. I haven't looked at how C++ co-routines are implemented, but would they be able to reuse this feature (assuming they would need a somewhat similar feature in mid- and back-end).

I think it's generic enough that other languages could use it. The proposed context prefix appears to be:

  struct SwiftAsyncContext {
    struct SwiftAsyncContext *callerFrame;
    void *callerReturnAddress;
  };

File off the name `Swift` and I think any front-end could construct such a structure. Unfortunately, I think it would be an ABI break for C++ at this stage; an old caller would pass rubbish into a function trying to store this context and that's not good.

> As this seems to be introducing new ABI - do you have an idea of what the most appropriate ABI specification is this would be best documented in?

I think we should document the reusable bits, so probably up to that struct above and state that what follows those two pointers is up to the language.

> Do I guess correctly that this is not a Darwin-only feature?

That's right. I think it's mostly a quality-of-life feature (so it's not critical for me to get this done on AArch32 right now, for example), but Swift runs on Linux & Windows too, and I'd hope they can use it (even if the default system tools 
don't catch up for a while, or ever). I haven't done extensive testing on them yet though.

> If this is really swift-specific (i.e. it does not seem to be a good trade-off to have this mid/back-end feature support similar language features for multiple front-ends), I guess this is Swift-specific ABI. Do I guess correctly that there isn't really a specification for Swift-specific ABI - it's purely defined by its primary implementation?

I think that's right.



================
Comment at: llvm/lib/Target/AArch64/AArch64FrameLowering.cpp:49-53
 // |- - - - - - - - - - - - - - - - - -|    | callee saves are swapped,
 // |                                   |    | (frame record first)
 // | prev_fp, prev_lr                  | <--'
 // | (a.k.a. "frame record")           |
 // |-----------------------------------| <- fp(=x29)
----------------
kristof.beyls wrote:
> Would it be useful to update the documentation here on the frame record for AArch64 to cover "So when one of these contexts is present it will extend the usual (on AArch64) [FP, LR] frame record by putting the context just before it: [Ctx, FP, LR]"?
Yep, I'll do that.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95044/new/

https://reviews.llvm.org/D95044