[Performance diagnostics] Enable checking of throw instructions #77752
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This builds on #77748. That PR made typed throws avoid allocations in practice, lifting a restriction. This PR removes the hack that allowed untyped throws through the performance-annotation checker, even though they would allocate. So this PR tightens up performance annotation checking in a way that may reject existing code (that should always have been rejected). |
|
@swift-ci please smoke test |
eeckstein
reviewed
Nov 21, 2024
Prior to throwing, Swift emits a call to `swift_willThrow(Typed)`, which allows various diagnostic tools (such as debuggers and testing libraries) to intercept errors at the point where they are initially thrown. Since `swift_willThrow(Typed)` can be hooked by arbitrary code at runtime, there is no way for it to meet performance constraints like @_noLocks or @_noAllocation. Therefore, in a function that has those performance constraints specified, disable emission of the call to `swift_willThrow(Typed)`. Fixes rdar://140230684.
DougGregor
force-pushed
the
perf-diag-check-throws
branch
from
c354f90 to
7d73aab
Compare
|
Rebased on top of #77780, removed |
|
@swift-ci please smoke test |
DougGregor
force-pushed
the
perf-diag-check-throws
branch
from
7d73aab to
131bd17
Compare
|
@swift-ci please smoke test |
When performance diagnostics were introduced, typed throws didn't exist so it was not generally possible to have throws anywhere without triggering performance diagnostics. As a short term hack, we disabled checking of `throw` instructions and the basic blocks that terminate in a `throw`. Now that typed throws is available and can be used to eliminate allocations with error handling, remove all of the hacks. We'll now diagnose attempts to throw or catch existential values (e.g., the `any Error` used for untyped throws), but typed throws are fine.
DougGregor
force-pushed
the
perf-diag-check-throws
branch
from
131bd17 to
1d3332d
Compare
|
@swift-ci please smoke test |
|
@swift-ci please smoke test macOS |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When performance diagnostics were introduced, typed throws didn't exist
so it was not generally possible to have throws anywhere without
triggering performance diagnostics. As a short term hack, we disabled
checking of
throwinstructions and the basic blocks that terminatein a
throw.Now that typed throws is available and can be used to eliminate
allocations with error handling, remove all of the hacks. We'll now
diagnose attempts to throw or catch existential values (e.g., the
any Errorused for untyped throws), but typed throws are fine.