Skip to content

Clean up SIL witness table deserialization #21476

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

Merged
merged 8 commits into from
Dec 21, 2018

Conversation

slavapestov
Copy link
Contributor

SILModule::lookUpWitnessTable() had a weird behavior where it would only deserialize a witness table if there was already a declaration for it. As a result, various callers had to ensure that the witness table declaration exists. We would also pre-declare any witness tables referenced from SIL instructions when they were created.

None of this was really necessary; instead, lookUpWitnessTable() should just create the declaration if it was asked to deserialize.

This is a nice cleanup in itself, but is mostly meant to support the constexpr work by @marcrasi and @ravikandhadai.

…ration()

All callers were doing the same thing here, so move it inside the
function. Also, change getRootNormalConformance(), which is deprecated,
to getRootConformance().
Note that SILModule::lookUpWitnessTable() only attempts to deserialize
the witness table if we already have a declaration. In the
SILLinkerVisitor, we would call lookUpWitnessTable(), see if it returned
null, create a declaration, and if deserializeLazily is true, we would
call lookUpWitnessTable() again; this time, there was a declaration, and
we would deserialize the witness table.

However, if there was already a witness table declaration when we first
called lookUpWitnessTable(), we would trigger deserialization, even if
deserializeLazily is false.

Change the first call to pass false.

I had to update a couple of tests; I believe they were already somewhat
nonsensical.
This is actually NFC: We should have already deserialized everything
we need at this point, and because of large loadable types and
address lowering, deserializing more stuff in IRGen is not valid,
and in fact we check for this and refuse to deserialize.
Should be NFC for now, since callers either assume the linker pass
has run, or they manually call createWitnessTableDeclaration().
Now that SILModule::lookUpWitnessTable() can create a declaration
if needed, we don't have to call it twice.
…ady exists

I discovered this while testing the new commit, since it results in fewer
witness tables getting pre-declared.

There was a SIL test that relied on the old behavior; I'm going to explicitly
declare those witness tables as public_external to preserve behavior.
…structions

Another simplification made possible by the change to
SILModule::lookUpWitnessTable().
The code becomes simpler if we fold it into its only caller.
@slavapestov
Copy link
Contributor Author

@swift-ci Please test

@slavapestov
Copy link
Contributor Author

@swift-ci Please test source compatibility

@slavapestov
Copy link
Contributor Author

The change is pretty small but I split it up into multiple commits and tested each one since it's all a bit subtle. I think the end result is much easier to reason about though.

Copy link
Contributor

@jckarter jckarter left a comment

Choose a reason for hiding this comment

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

LGTM

@slavapestov
Copy link
Contributor Author

@swift-ci Please benchmark

@swift-ci
Copy link
Contributor

Build comment file:

Performance: -O

TEST OLD NEW DELTA RATIO
Regression
DataSetCountSmall 137 148 +8.0% 0.93x (?)

Performance: -Osize

TEST OLD NEW DELTA RATIO
Regression
DataSetCountSmall 140 151 +7.9% 0.93x
How to read the data The 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
regressions before you merge the PR.

Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview
  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB
--------------

@slavapestov slavapestov merged commit f1bce6d into swiftlang:master Dec 21, 2018
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