Improve @guaranteed args handling in ARCSequenceOpts #33267
Conversation
|
@swift-ci benchmark |
Performance: -O
Code size: -OPerformance: -Osize
Code size: -OsizePerformance: -Onone
Code size: -swiftlibsHow to read the dataThe tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.If you see any unexpected regressions, you should consider fixing the Noise: Sometimes the performance results (not code size!) contain false Hardware Overview |
|
@swift-ci test |
|
Build failed |
| if (!mayDecrementRefCount(PotentialGuaranteedUser, getRCRoot(), AA)) { | ||
| return false; | ||
| } | ||
|
|
There was a problem hiding this comment.
I think it would be more clear if the comment explained that by returning, we allow handlePotentialUser to treat this like a normal use and transition to MightBeUsed
It's really too bad that we need to check handlePotentialDecrement again after this, because it's expensive (and confusing). But these helpers are really contorted and I don't know how to fix it.
| if (!mayDecrementRefCount(PotentialGuaranteedUser, getRCRoot(), AA)) { | ||
| return false; | ||
| } | ||
|
|
There was a problem hiding this comment.
Same feedback on the comment applies here.
meg-gupta
force-pushed
the
arcseqchanges
branch
2 times, most recently
from
e38e6ec to
de0cc6f
Compare
|
@swift-ci test |
@guaranteed args are treated conservatively in ARCSequenceOpts. A function call with a @guaranteed arg is assumed to decrement refcount of the @guaranteed arg. With this change, use swift::mayDecrementRefCount which uses EscapeAnalysis to determine if we need to transition conservatively at the instruction being visited.
|
Build failed |
meg-gupta
force-pushed
the
arcseqchanges
branch
from
de0cc6f to
d172129
Compare
|
Build failed |
|
@swift-ci test linux platform |
|
Build failed |
@guaranteed args are treated conservatively in ARCSequenceOpts. A function call with a @guaranteed arg is assumed to decrement refcount of the @guaranteed arg.
handleGuaranteedUsertransitions conservatively from aDecrementrefcount state toMightBeDecrementedrefcount state on a guaranteed use. Since an apply with a guaranteed arg that does not escape cannot decrement the refcount. This conservative transition is unnecessary. For such cases where the instruction being visited cannot decrement the refcount we should fallback tohandleUserwhich correctly transitions fromDecrementrefcount state toMightBeUsedfor uses where refcount cannot be decremented.With this change, use
swift::mayDecrementRefCountwhich uses EscapeAnalysis to determine if we need to transition conservatively at the instruction being visited.