-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[ownership] Loosen restrictions around what we specialize and add generic specialization tests behind a flag. #32397
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
[ownership] Loosen restrictions around what we specialize and add generic specialization tests behind a flag. #32397
Conversation
lib/SILOptimizer/Utils/Generics.cpp
Outdated
ArrayRef<SILValue> values) { | ||
for (SILValue v : values) { | ||
if (auto *lbi = dyn_cast<LoadBorrowInst>(v)) { | ||
builder.createEndBorrow(loc, lbi); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am a little nervous about this. I think I am going to change values here to have a bit that says it needs an end borrow or something like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right: what if there was a load_borrow before specialization? The you would insert a wrong end_borrow
|
||
// Look through copy_value. | ||
if (auto *cvi = dyn_cast<CopyValueInst>(User)) { | ||
llvm::copy(cvi->getUses(), std::back_inserter(worklist)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added this b/c some of the tests around recursive specialization started failing b/c it couldn't look through these instructions/ignore incidental instructions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
basically lgtm.
Request for changes only for a better way to decide on inserting an end_borrow (see my comment)
lib/SILOptimizer/Utils/Generics.cpp
Outdated
ArrayRef<SILValue> values) { | ||
for (SILValue v : values) { | ||
if (auto *lbi = dyn_cast<LoadBorrowInst>(v)) { | ||
builder.createEndBorrow(loc, lbi); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right: what if there was a load_borrow before specialization? The you would insert a wrong end_borrow
@eeckstein I fixed it by using a SmallBitVector. I learned about something new that I didn't know about: SmallBitVector now has an iterator for set bit indices! So you can just do:
instead of:
|
745f482
to
2e6f46c
Compare
@swift-ci test |
lib/SILOptimizer/Utils/Generics.cpp
Outdated
@@ -1969,6 +1997,10 @@ static ApplySite replaceWithSpecializedCallee(ApplySite applySite, | |||
assert(resultBlock->getSinglePredecessorBlock() == tai->getParent()); | |||
auto *newTAI = builder.createTryApply(loc, callee, subs, arguments, | |||
resultBlock, tai->getErrorBB()); | |||
FullApplySite(newTAI).insertAfterFullEvaluation( | |||
[&](SILBasicBlock::iterator insertPt) { | |||
cleanupCallArguments(builder, loc, arguments, argsNeedEndBorrow); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm... I think I need to create a new SILBuilder here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am going to try to break this. This to not fail says we are missing code coverage.
Build failed |
Build failed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm!
@swift-ci test |
Build failed |
Build failed |
b3e1043
to
77b094a
Compare
I was correct that we were missing code coverage. I added the missing code coverage of try_apply/begin_apply. |
@swift-ci test |
Build failed |
Build failed |
Build failed |
@swift-ci test windows platform |
@swift-ci test OS X platform |
OS X failure was a sandbox issue |
Build failed |
I took a look at why we are failing/hitting the verifier error. The reason why is that there is a debug_value on self that is after the store [init] of self at the beginning of a function to materialize the argument. |
77b094a
to
f4d40c6
Compare
Reproduced the error. |
Interesting:
|
Bug in the reabstract thunk generation code. |
Found the bug. It was my bug. Thank god for ownership verification = ). |
I am going to try again tonight. |
f4d40c6
to
275a1e6
Compare
Tracked down the problem. The problem was that there was some misleading code that seemed like it was only handling apply inst. Instead it was also handling try_apply, but returning the normal block argument as the "result". This seems like a general useful property, so I put it into a helper on ApplySite. Now it all works. |
@swift-ci test |
@swift-ci test source compatibility |
Build failed |
Build failed |
@swift-ci test windows platform |
Found more missing test coverage. We don't ever generate one of these reabstraction thunks with |
…eric specialization tests behind a flag. The idea is that this will let me remove these assertions that were in place to make sure we were really conservative around specializing ownership code. For me to remove that I need to be able to actually test out this code (since I think there are some code paths where this will trigger in other parts of the compiler now). So to work out the kinks, I added a flag that allows for the generic specializer to process ownership code and translated most of the .sil test cases/fixed any bugs that I found. This hopefully will expose anything that is missing. NOTE: I have not enabled the generic specializer running in ownership in the pipeline. This is just a step in that direction by adding tests/etc.
275a1e6
to
1b97c03
Compare
@swift-ci test |
@swift-ci test source compatibility |
@swift-ci test windows platform |
1 similar comment
@swift-ci test windows platform |
Looks like Source Compatibility matches the state on ci.swift.org. It isn't this commit. |
The idea is that this will let me remove these assertions that were in place to
make sure we were really conservative around specializing ownership code. For me
to remove that I need to be able to actually test out this code (since I think
there are some code paths where this will trigger in other parts of the compiler
now).
So to work out the kinks, I added a flag that allows for the generic specializer
to process ownership code and translated most of the .sil test cases/fixed any
bugs that I found. This hopefully will expose anything that is missing.
NOTE: I have not enabled the generic specializer running in ownership in the
pipeline. This is just a step in that direction by adding tests/etc.