Skip to content

[RemoteMirror] Remove compiler code to emit spare bit info in reflection metadata #74230

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

tbkka
Copy link
Contributor

@tbkka tbkka commented Jun 7, 2024

This mostly reverts "[RemoteMirror] Get spare bit info from reflection records (#40906)"
This mostly reverts commit 4d91b45.

PR #40906 implemented RemoteMirror support for projecting multi-payload enums. This included a lot of core infrastructure for reasoning about MPE layouts and also included changes to the compiler to emit spare bit mask data. However, I recently figured out how RemoteMirror can in fact directly compute spare bit mask information without the additional reflection information. PRs #73491 and #74145 updated RemoteMirror to do the direct calculation and so RemoteMirror no longer uses the MPE spare bit mask information from the compiler. This PR removes the compiler logic to emit such data and the RemoteMirror support for locating the information.

…ion metadata

This mostly reverts "[RemoteMirror] Get spare bit info from reflection records (swiftlang#40906)"
I recently figured out that RemoteMirror can compute all the spare
bit data directly without requiring this information.  So let's
remove it to save some space in binaries.

This mostly reverts commit 4d91b45.
@tbkka tbkka requested review from mikeash, al45tair and a team as code owners June 7, 2024 23:43
@tbkka tbkka requested review from augusto2112, mikeash, kastiglione and btroller and removed request for a team, mikeash and al45tair June 7, 2024 23:43
@tbkka
Copy link
Contributor Author

tbkka commented Jun 7, 2024

@swift-ci Please test

Copy link
Contributor

@augusto2112 augusto2112 left a comment

Choose a reason for hiding this comment

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

I think not having to emit the multipayload descriptor would be really nice, but I'm worried if this wouldn't break remote mirrors clients that shipped with an older version of the library that don't include the changes in #73491 and #74145, and would therefore would be unable to derive the multipayload type information. What do you think?

Note: this will probably not build because lldb implements MultiPayloadEnumDescriptorBase in DWARFASTParserSwiftDescriptorFinder.cpp, so you'll need an accompanying lldb patch removing that oo.

@tbkka
Copy link
Contributor Author

tbkka commented Jun 8, 2024

The concern about older versions of the library that may still be in circulation seems like a good argument for not merging this to 6.0.

I'm in the process of preparing the accompanying lldb patch. I hope to have that ready soon.

Copy link
Contributor

@mikeash mikeash left a comment

Choose a reason for hiding this comment

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

Echoing @augusto2112's cautions about breaking older clients. This would produce a degraded experience but not an entirely broken one, so it should be OK to do this at some point, we just have to decide when. Another option would be to keep this around with deployment target gating, but that seems excessive for this particular thing.

@tbkka
Copy link
Contributor Author

tbkka commented Jun 13, 2024

Based on the discussion above, I've decided to break this up into a couple of separate submissions:

#74394 just removes the remaining RemoteMirror code for looking up the no-longer-needed reflection metadata. It leaves just enough stub logic for LLDB to still build, and it leaves the compiler code to emit that metadata.

Once LLDB is updated, we can remove the last stubs from RemoteMirror.

I'll trim this PR down to just cover removing the compiler emission -- we can debate when would be the appropriate time to land that.

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.

3 participants