-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
codegen_llvm/llvm_type: avoid matching on the Rust type #115240
Merged
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
0fde82f
codegen_llvm/llvm_type: avoid matching on the Rust type
RalfJung dc70fb6
also avoid matching on the type in scalar_pair_element_llvm_type
RalfJung 99d76a4
carry out the same changes in the gcc backend
RalfJung 9b9cb51
remove an unused argument
RalfJung File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Sorry for seeing this so late, but, if not made clear so far by anyone else:
the special cases you removed are simultaneously sound and obsolete.
They're sound because they only affect pointer types' pointee types (which doesn't impact ABI on it own), and they're obsolete thanks to LLVM opaque pointers (making the removal welcome!).
You can kinda tell they were working fine because e.g.
Option<&String>
would look likei64*
, whereas the inner&String
would actually be{i8*, i64, i64}*
- worst case, it would pessimize some badly written LLVM optimizations, but all of those concerns should be gone now.In fact, some of this code can very likely be simplified!
scalar_pair_element_llvm_type
only exists in the form it does because it needed to special-case wide pointers, but now each component of the scalar pair can be independently converted to LLVM.It might even make sense to remove caches like
scalar_lltypes
and instead have something much simpler keyed byPrimitive
- the existingscalar_llvm_type_at
might be good enough, even, and I would argue the cache only existed because of the pointer cases, and can now be fully removed.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.
Yes that was my conclusion, too. That still makes this PR a good cleanup, no? :)
But looking at these special cases led me to ones that aren't sound (see the recent ABI issues I opened), so the cleanup of obsolete-but-sound type matching was still worth it.
I'm sure there's further simplification possible.