Skip to content
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

Implement LLVM IR Virtual Function Elimination for Swift classes. #39128

Merged
merged 1 commit into from
Sep 14, 2021

Conversation

kubamracek
Copy link
Contributor

@kubamracek kubamracek commented Sep 1, 2021

  • Virtual calls are done via a @llvm.type.checked.load instrinsic call with a type identifier
  • Type identifier of a vfunc is the base method's mangling
  • Type descriptors and class metadata get !type markers that list offsets and type identifiers of all vfuncs
  • The -enable-llvm-vfe frontend flag enables VFE
  • Two added tests verify the behavior on IR and by executing a program

Depends on changes in LLVM (some unmerged yet): https://reviews.llvm.org/D107645, https://reviews.llvm.org/D108741, https://reviews.llvm.org/D109114, https://reviews.llvm.org/D109169.

var->addTypeMetadata(offset, typeIdForMethod(*this, method));
}

switch (getOptions().VCallVisibility) {
Copy link
Member

Choose a reason for hiding this comment

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

Why not deriving the VCall visibility from the method visibility?
Setting the visibility for all calls sounds dangerous, e.g. if a public method gets a "File" visibility.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's right, it is dangerous -- incorrectly set visibility will cause miscompiles. I've added this to be used in tests, where I need to make sure the method isn't going to eliminated by the SIL optimizer, so it's public, but I want the LLVM IR optimizer to eliminate it, therefore the vcall visibility set to "file".

Open to any better suggestions?

Copy link
Member

Choose a reason for hiding this comment

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

You can call a private/internal method from a function, annotated with @_optimize(none). That will keep the virtual call alive

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Changed the PR to infer the vtable visibility from the class decl's access scope visibility.

@@ -334,6 +334,33 @@ void IRGenModule::emitNonoverriddenMethodDescriptor(const SILVTable *VTable,
getAddrOfLLVMVariable(entity, init, DebugTypeInfo());
}

void IRGenModule::addVTableTypeMetadata(llvm::GlobalVariable *var,
SmallVector<std::pair<Size, SILDeclRef>, 8> vtableEntries) {
if (!getOptions().VirtualFunctionElimination)
Copy link
Member

Choose a reason for hiding this comment

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

This is already checked at the call site

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removed.

@kubamracek kubamracek changed the title Implement Virtual Function Elimination for Swift classes. Implement LLVM IR Virtual Function Elimination for Swift classes. Sep 2, 2021
Copy link
Member

@eeckstein eeckstein left a comment

Choose a reason for hiding this comment

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

LGTM.
It would be good if @aschwaighofer takes a look, too.

Copy link
Member

@aschwaighofer aschwaighofer left a comment

Choose a reason for hiding this comment

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

lgtm

@kubamracek
Copy link
Contributor Author

@swift-ci please test

@swift-ci
Copy link
Collaborator

swift-ci commented Sep 9, 2021

Build failed
Swift Test OS X Platform
Git Sha - 8455480dad16618ccbf3a46e99a1772a2aa382d1

@kubamracek
Copy link
Contributor Author

@swift-ci please test

@swift-ci
Copy link
Collaborator

swift-ci commented Sep 9, 2021

Build failed
Swift Test OS X Platform
Git Sha - bece055d6b779f9b8b941affeb8cab5f8d52030e

@kubamracek
Copy link
Contributor Author

@swift-ci please test

@kubamracek
Copy link
Contributor Author

@swift-ci please test

- Virtual calls are done via a @llvm.type.checked.load instrinsic call with a type identifier
- Type identifier of a vfunc is the base method's mangling
- Type descriptors and class metadata get !type markers that list offsets and type identifiers of all vfuncs
- The -enable-llvm-vfe frontend flag enables VFE
- Two added tests verify the behavior on IR and by executing a program
@kubamracek
Copy link
Contributor Author

@swift-ci please test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants