Skip to content

[Distributed] Implement distributed computed properties via special accessor #59700

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

xedin
Copy link
Contributor

@xedin xedin commented Jun 24, 2022

This is an alternative implementation of distributed computed properties that introduces
a new DistributedThunk accessor kind, new access strategy, and semantics.

A reference to a getter of a distributed computed property is transparently replaced by
its thunk during SILGen (the semantics are the same for both distributed methods and
distributed computed properties).

rdar://91283164

@xedin xedin requested review from ktoso and DougGregor June 24, 2022 23:50
@xedin
Copy link
Contributor Author

xedin commented Jun 24, 2022

@DougGregor and @ktoso this is still a draft but it's functional. I'd probably need to cherry-pick some of the changes from original implementation to make it complete. Please let me know what you think.

@ktoso ktoso added the distributed Feature → concurrency: distributed actor label Jun 24, 2022
@xedin xedin force-pushed the distributed-computed-properties-via-accessor-thunk branch from 97d1f15 to c0cea20 Compare June 27, 2022 20:30
@xedin xedin marked this pull request as ready for review June 27, 2022 21:31
@xedin xedin force-pushed the distributed-computed-properties-via-accessor-thunk branch from ff3c70f to b9a616d Compare June 27, 2022 21:42

/// The access is to a computed distributed property, and thus the
/// get-accessor is a distributed thunk which may perform a remote call.
DispatchToDistributedThunk,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@xedin xedin force-pushed the distributed-computed-properties-via-accessor-thunk branch from b9a616d to f67b09f Compare June 27, 2022 22:24
Copy link
Contributor

@ktoso ktoso left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me! Though needs a @DougGregor review as well to see if it looks good now :)

@xedin
Copy link
Contributor Author

xedin commented Jun 27, 2022

@swift-ci please test

@xedin
Copy link
Contributor Author

xedin commented Jun 28, 2022

@swift-ci please test Linux platform

@ktoso
Copy link
Contributor

ktoso commented Jun 29, 2022

Cherry picked it over: #59774

Copy link
Member

@DougGregor DougGregor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm concerned about the mangling, but the rest is polish.

@@ -735,6 +735,12 @@ CONTEXTUAL_SIMPLE_DECL_ATTR(_local, KnownToBeLocal,
APIBreakingToAdd | APIBreakingToRemove,
130)

SIMPLE_DECL_ATTR(_distributed_thunk, DistributedThunk,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this an attribute rather than a bit on the Decl? It'll never be user-spelled, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, cannot be spelled. It could be an attribute on the decl, wasn't sure which one is better.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Switched to use a bit in the declaration and changed serialization accordingly.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

GetDistributedThunkRequest,
FuncDecl *(llvm::PointerUnion<VarDecl *, AbstractFunctionDecl *>),
RequestFlags::Cached> {
using Originator = llvm::PointerUnion<VarDecl *, AbstractFunctionDecl *>;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect we'll be replacing VarDecl with AbstractStorageDecl to get subscripts at some point :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generalized Originator to accept AbstractStorageDecl and AbstractFunctionDecl.

appendContextOf(decl);
appendDeclName(accessor->getStorage());
appendDeclType(accessor, FunctionMangling);
appendOperator("F");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mangling changes need to update docs/ABI/Mangling.rst, the demangler, the remanglers, and add a test (e.g., in test/Demangle/Inputs/manglings.txt) to make sure the whole round-trip works. Also, is F here actually unused? I would have expected that the ACCESSOR production would be extended for this case, so distributed thunks would go through appendAccessorEntity

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Distributed thunk accessors are mangled the same way as distributed funcs because runtime needs a function type, if we want to add a new mangling for accessor thunks we'd need to rework a runtime aspects of remote calls. I'm going to add a comment here explaining this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a comment about this.

// which are allowed, but subject to the same implicit throws/async
// as all other distributed function declarations.
if (var->isDistributed()) {
return true;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This surprises me, and I don't think we should make this change here. varIsSafeAcrossActors is meant to mean "you can access this without hopping to the actor", which is not the case for distributed properties.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ktoso I removed the check because as Doug mentioned it doesn't seem correct.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right that seemed wrong -- thank you!

.fixItInsert(decl->getAttributeInsertionLoc(true), "distributed ");
// Cannot reference subscripts, or stored properties.
auto var = dyn_cast<VarDecl>(decl);
if (isa<SubscriptDecl>(decl) || var) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The rewritten logic here silently accepts declaration kinds it doesn't understand. I'm not sure if I can trigger a bug based on this, but the prior formulation (!func || !func->isDistributed()) was more robust. Can we use more straightforward logic here like:

if (auto func = dyn_cast<AbstractFunctionDecl>(decl)) {
 handle funcs and return
}

if (auto var = dyn_cast<VarDecl>(decl)) {
  handle vars and return
}

diagnose and return None

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed!

ktoso and others added 12 commits June 29, 2022 14:49
`DistributedThunk` is to be used while accessing 'distributed'
computed property outside of its actor context.
This strategy is used to dispatch accesses to 'distributed' computed
property to distributed thunk accessor instead of a regular getter
when access happen outside actor isolation context.
The flag is used to distinguish between regular functions/accessors
and synthesized distributed thunks.
…uted thunks

Distributed thunks have to refer to the "local" version
of the property directly with implicit `self.` base.
@xedin xedin force-pushed the distributed-computed-properties-via-accessor-thunk branch from f67b09f to d9a0130 Compare June 29, 2022 21:50
@xedin
Copy link
Contributor Author

xedin commented Jun 29, 2022

@swift-ci please test

Copy link
Member

@DougGregor DougGregor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, thank you!

@xedin
Copy link
Contributor Author

xedin commented Jun 30, 2022

@swift-ci please test

// appendOperator("F");
// appendSymbolKind(SymbolKind::DistributedThunk);
// return finalize();
// ```
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for the TODO, that's on me after we fixed the SILDeclRefs

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, no worries!

It used to be an accessor but that is not required because
SILDeclRef controls mangling which is the most imprortant
and could be used to emit the right reference.
@xedin xedin force-pushed the distributed-computed-properties-via-accessor-thunk branch from ac582b2 to 2480c99 Compare June 30, 2022 00:58
@xedin
Copy link
Contributor Author

xedin commented Jun 30, 2022

@swift-ci please test

@ktoso
Copy link
Contributor

ktoso commented Jun 30, 2022

I'll cherry pick it over to 5.7 👍

@xedin
Copy link
Contributor Author

xedin commented Jun 30, 2022

@swift-ci please test Windows platform

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
distributed Feature → concurrency: distributed actor
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants