Skip to content

[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

Conversation

gottesmm
Copy link
Contributor

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.

@gottesmm gottesmm requested a review from eeckstein June 15, 2020 23:06
ArrayRef<SILValue> values) {
for (SILValue v : values) {
if (auto *lbi = dyn_cast<LoadBorrowInst>(v)) {
builder.createEndBorrow(loc, lbi);
Copy link
Contributor Author

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.

Copy link
Contributor

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));
Copy link
Contributor Author

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.

Copy link
Contributor

@eeckstein eeckstein left a 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)

ArrayRef<SILValue> values) {
for (SILValue v : values) {
if (auto *lbi = dyn_cast<LoadBorrowInst>(v)) {
builder.createEndBorrow(loc, lbi);
Copy link
Contributor

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

@gottesmm
Copy link
Contributor Author

gottesmm commented Jun 16, 2020

@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:

for (int index : bitVector.set_bits()) { ... }

instead of:

for (int index = bitVector.find_first(); index != -1;
       index = bitVector.find_next(index)) { ... }

@gottesmm gottesmm force-pushed the pr-92e92ba00c4c145dbd650430947c43d7b3a743d5 branch from 745f482 to 2e6f46c Compare June 16, 2020 19:00
@gottesmm gottesmm requested a review from eeckstein June 16, 2020 19:00
@gottesmm
Copy link
Contributor Author

@swift-ci test

@@ -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);
Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 745f482a722942492f37429ef61b2ff1be26468b

@swift-ci
Copy link
Contributor

Build failed
Swift Test Linux Platform
Git Sha - 745f482a722942492f37429ef61b2ff1be26468b

Copy link
Contributor

@eeckstein eeckstein left a comment

Choose a reason for hiding this comment

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

lgtm!

@gottesmm
Copy link
Contributor Author

@swift-ci test

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 2e6f46c0627e4f51518f83cf06ed92856f4c1ad3

@swift-ci
Copy link
Contributor

Build failed
Swift Test Linux Platform
Git Sha - 2e6f46c0627e4f51518f83cf06ed92856f4c1ad3

@gottesmm gottesmm force-pushed the pr-92e92ba00c4c145dbd650430947c43d7b3a743d5 branch 2 times, most recently from b3e1043 to 77b094a Compare June 23, 2020 01:08
@gottesmm
Copy link
Contributor Author

I was correct that we were missing code coverage. I added the missing code coverage of try_apply/begin_apply.

@gottesmm
Copy link
Contributor Author

@swift-ci test

2 similar comments
@gottesmm
Copy link
Contributor Author

@swift-ci test

@gottesmm
Copy link
Contributor Author

@swift-ci test

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 2e6f46c0627e4f51518f83cf06ed92856f4c1ad3

@swift-ci
Copy link
Contributor

Build failed
Swift Test Linux Platform
Git Sha - 2e6f46c0627e4f51518f83cf06ed92856f4c1ad3

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 2e6f46c0627e4f51518f83cf06ed92856f4c1ad3

@gottesmm
Copy link
Contributor Author

@swift-ci test windows platform

@gottesmm
Copy link
Contributor Author

@swift-ci test OS X platform

@gottesmm
Copy link
Contributor Author

OS X failure was a sandbox issue

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 77b094a470e872ee0814eb992487eded08dd6e40

@gottesmm
Copy link
Contributor Author

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.

@gottesmm gottesmm force-pushed the pr-92e92ba00c4c145dbd650430947c43d7b3a743d5 branch from 77b094a to f4d40c6 Compare June 26, 2020 20:23
@gottesmm
Copy link
Contributor Author

Reproduced the error.

@gottesmm
Copy link
Contributor Author

Interesting:

// thunk for @escaping @callee_guaranteed (@inout A, @guaranteed PathArgument) -> (@error @owned Error)
sil shared [transparent] [serializable] [reabstraction_thunk] [ossa] @$sx10TSCUtility12PathArgumentVs5Error_pIeglgzo_xACsAD_pIeglnzo_8Commands11ToolOptionsCRbzlTR : $@convention(thin) <Options where Options : ToolOptions> (@inout Options, @in_guaranteed PathArgument, @guaranteed @callee_guaranteed (@inout Options, @guaranteed PathArgument) -> @error Error) -> @error Error {
// %0                                             // user: %4
// %1                                             // user: %3
// %2                                             // user: %4
bb0(%0 : $*Options, %1 : $*PathArgument, %2 : @guaranteed $@callee_guaranteed (@inout Options, @guaranteed PathArgument) -> @error Error):
  %3 = load_borrow %1 : $*PathArgument            // users: %7, %10, %4
  try_apply %2(%0, %3) : $@callee_guaranteed (@inout Options, @guaranteed PathArgument) -> @error Error, normal bb1, error bb2 // id: %4

bb1(%5 : $()):                                    // Preds: bb0
  %6 = tuple ()                                   // user: %8
  end_borrow %3 : $PathArgument                   // id: %7
  return %6 : $()                                 // id: %8

// %9                                             // user: %11
bb2(%9 : @owned $Error):                          // Preds: bb0
  end_borrow %3 : $PathArgument                   // id: %10
  throw %9 : $Error                               // id: %11
} // end sil function '$sx10TSCUtility12PathArgumentVs5Error_pIeglgzo_xACsAD_pIeglnzo_8Commands11ToolOptionsCRbzlTR'

@gottesmm
Copy link
Contributor Author

Bug in the reabstract thunk generation code.

@gottesmm
Copy link
Contributor Author

Found the bug. It was my bug. Thank god for ownership verification = ).

@gottesmm
Copy link
Contributor Author

gottesmm commented Jul 1, 2020

I am going to try again tonight.

@gottesmm gottesmm force-pushed the pr-92e92ba00c4c145dbd650430947c43d7b3a743d5 branch from f4d40c6 to 275a1e6 Compare July 1, 2020 06:32
@gottesmm
Copy link
Contributor Author

gottesmm commented Jul 1, 2020

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.

@gottesmm
Copy link
Contributor Author

gottesmm commented Jul 1, 2020

@swift-ci test

2 similar comments
@gottesmm
Copy link
Contributor Author

gottesmm commented Jul 1, 2020

@swift-ci test

@gottesmm
Copy link
Contributor Author

gottesmm commented Jul 1, 2020

@swift-ci test

@gottesmm
Copy link
Contributor Author

gottesmm commented Jul 1, 2020

@swift-ci test source compatibility

2 similar comments
@gottesmm
Copy link
Contributor Author

gottesmm commented Jul 1, 2020

@swift-ci test source compatibility

@gottesmm
Copy link
Contributor Author

gottesmm commented Jul 1, 2020

@swift-ci test source compatibility

@swift-ci
Copy link
Contributor

swift-ci commented Jul 1, 2020

Build failed
Swift Test Linux Platform
Git Sha - f4d40c6d974b4288ee3b61e01c9ccf629a12bc67

@swift-ci
Copy link
Contributor

swift-ci commented Jul 1, 2020

Build failed
Swift Test OS X Platform
Git Sha - f4d40c6d974b4288ee3b61e01c9ccf629a12bc67

@gottesmm
Copy link
Contributor Author

gottesmm commented Jul 1, 2020

@swift-ci test windows platform

@gottesmm
Copy link
Contributor Author

gottesmm commented Jul 2, 2020

Found more missing test coverage. We don't ever generate one of these reabstraction thunks with @out parameters in the test suite...

…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.
@gottesmm gottesmm force-pushed the pr-92e92ba00c4c145dbd650430947c43d7b3a743d5 branch from 275a1e6 to 1b97c03 Compare July 3, 2020 09:54
@gottesmm
Copy link
Contributor Author

gottesmm commented Jul 3, 2020

@swift-ci test

2 similar comments
@gottesmm
Copy link
Contributor Author

gottesmm commented Jul 3, 2020

@swift-ci test

@gottesmm
Copy link
Contributor Author

gottesmm commented Jul 3, 2020

@swift-ci test

@gottesmm
Copy link
Contributor Author

gottesmm commented Jul 3, 2020

@swift-ci test source compatibility

2 similar comments
@gottesmm
Copy link
Contributor Author

gottesmm commented Jul 3, 2020

@swift-ci test source compatibility

@gottesmm
Copy link
Contributor Author

gottesmm commented Jul 3, 2020

@swift-ci test source compatibility

@gottesmm
Copy link
Contributor Author

gottesmm commented Jul 3, 2020

@swift-ci test windows platform

1 similar comment
@gottesmm
Copy link
Contributor Author

gottesmm commented Jul 3, 2020

@swift-ci test windows platform

@gottesmm
Copy link
Contributor Author

gottesmm commented Jul 4, 2020

Looks like Source Compatibility matches the state on ci.swift.org. It isn't this commit.

@gottesmm gottesmm merged commit 8a1f2c6 into swiftlang:master Jul 4, 2020
@gottesmm gottesmm deleted the pr-92e92ba00c4c145dbd650430947c43d7b3a743d5 branch July 4, 2020 19:41
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.

4 participants