Eagerly emit getters at Onone. #75847
Conversation
|
@swift-ci smoke test |
lib/SIL/IR/SILDeclRef.cpp
Outdated
| @@ -387,6 +387,12 @@ bool SILDeclRef::hasUserWrittenCode() const { | |||
| llvm_unreachable("Unhandled case in switch!"); | |||
| } | |||
|
|
|||
| bool SILDeclRef::isGetter() const { | |||
| if (auto *accessor = dyn_cast_or_null<AccessorDecl>(getFuncDecl())) | |||
| return accessor->isGetter(); | |||
There was a problem hiding this comment.
Is this also going to be true for getters of ClangImporter-synthesized properties? We probably don't want to emit all of those.
There was a problem hiding this comment.
@slavapestov are those ObjC properties that are imported into Swift? Couldn't they also be accessed in the debugger?
There was a problem hiding this comment.
When evaluating an objective-C method call, the compiler generates the right thunks with shared linkage. That's why we don't want to force emission of those symbols if they're not needed. So perhaps the mayDelay computation needs to check the SIL linkage.
lib/SILGen/SILGen.cpp
Outdated
| // Implicit decls may be delayed if they can't be used externally. | ||
| auto linkage = constant.getLinkage(ForDefinition); | ||
| bool mayDelay = !constant.hasUserWrittenCode() && | ||
| bool mayDelay = !isOnoneGetter && !constant.hasUserWrittenCode() && |
There was a problem hiding this comment.
Maybe hasUserWrittenCode() should also return true for property wrappers? I see code coverage uses that flag too so the behavior should be consistent here.
There was a problem hiding this comment.
I thought about that too, since @hamishknight wrote it maybe they can chime in if that'd be appropriate or not. Maybe any getter whose storage is not implicit should be classified as user-written
There was a problem hiding this comment.
The intention behind hasUserWrittenCode was "does this decl contain any executable code that appears in a source file?", which is needed for code coverage since we don't want to emit coverage maps for anything that won't have any source regions. It's also used here because that check is also what we need for "do we need to emit this for SILOptimizer diagnostics?". It seems like we need a different check here for the debugger which is more "can this decl be referenced from user-written code?". I wonder if we can leverage the isSynthesized Decl flag for that, IIRC that's effectively what it models for implicit decls.
There was a problem hiding this comment.
Out of curiosity, should this behavior also be limited to cases where we're emitting debug info?
There was a problem hiding this comment.
Out of curiosity, should this behavior also be limited to cases where we're emitting debug info?
We usually avoid debug info interfering with code generation.
Force SILGen to also eagerly emit getters when compiling at Onone. The reason for this is that getters (even not user-written ones, generated by result builders) can, and are often called by users debugging swift programs, and should be available for that reason. rdar://133329303
augusto2112
force-pushed
the
keep-unused-getter
branch
from
52aea72 to
ae98212
Compare
|
@swift-ci smoke test |
Force SILGen to also eagerly emit getters when compiling at Onone. The reason for this is that getters (even not user-written ones, generated by result builders) can, and are often called by users debugging swift programs, and should be available for that reason.
rdar://133329303