Skip to content

early exit in TypeLowering for address-only type #1253

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
merged 2 commits into from
Feb 11, 2016

Conversation

dduan
Copy link
Contributor

@dduan dduan commented Feb 10, 2016

The logic that detects type circularity in TypeLowering has been replaced in
Sema. By exiting as soon as an address-only type is detected, we can avoid
walking the rest and gain some speedup.

@dduan
Copy link
Contributor Author

dduan commented Feb 10, 2016

@slavapestov
giphy

for (auto eltType : type.getElementTypes()) {
switch (classifyType(eltType, M, Sig, Expansion)) {
case LoweredTypeKind::Trivial:
continue;
case LoweredTypeKind::AddressOnly:
isAddressOnly = true;
return asImpl().handleAddressOnly(type);
continue;
Copy link
Contributor

Choose a reason for hiding this comment

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

The 'continue' is unreachable now

@slavapestov
Copy link
Contributor

Awesome, thank you so much!

@slavapestov
Copy link
Contributor

fox

The logic that detects type circularity in TypeLowering has been replaced in
Sema. By exiting as soon as an address-only type is detected, we can avoid
walking the rest and gain some speedup.
@dduan dduan force-pushed the delete_typelowering_dead_code branch from bf269de to 9203f20 Compare February 10, 2016 23:48
@dduan
Copy link
Contributor Author

dduan commented Feb 10, 2016

@slavapestov updated.

RecursiveErrorTypeLowering(SILType type)
: AddressOnlyTypeLowering(type) {}

bool isValid() const override {
Copy link
Contributor

Choose a reason for hiding this comment

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

One more nit-pick if you don't mind: It looks like TypeLowering::isValid() is never called anywhere and always returns true now, so it can be removed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is used in lib/SILOptimizer/Mandatory/PredictableMemOpt.cpp#44, but since it's alway true, we can remove that check now. Right?

Copy link
Contributor

Choose a reason for hiding this comment

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

I believe that check was added since we still run mandatory optimizations even if SILGen generated diagnostics.

So yeah, go ahead and remove it!

@slavapestov
Copy link
Contributor

@swift-ci Please test

@slavapestov slavapestov self-assigned this Feb 10, 2016
@slavapestov
Copy link
Contributor

Alright, looks good. I'll merge once CI is done.

@slavapestov
Copy link
Contributor

@swift-ci Please test

@dduan
Copy link
Contributor Author

dduan commented Feb 11, 2016

Thanks!

slavapestov added a commit that referenced this pull request Feb 11, 2016
early exit in TypeLowering for address-only type
@slavapestov slavapestov merged commit 5c97b21 into swiftlang:master Feb 11, 2016
@dduan dduan deleted the delete_typelowering_dead_code branch December 23, 2019 21:48
kateinoigakukun added a commit to kateinoigakukun/swift that referenced this pull request Sep 7, 2020
Test SwiftPM included in the distribution on CI
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.

2 participants