-
Notifications
You must be signed in to change notification settings - Fork 13.5k
Add A Version Of MachineModuleInfoWrapperPass
That Does Not Own Its Underlying MachineModuleInfo
#134554
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
matinraayai
wants to merge
8
commits into
llvm:main
Choose a base branch
from
matinraayai:mra/make-mmiwp-take-mmi-reference
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Add A Version Of MachineModuleInfoWrapperPass
That Does Not Own Its Underlying MachineModuleInfo
#134554
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
ed5c332
- Removed move constructor for MMI.
matinraayai 1a29779
Changed TargetMachine and CodeGenTargetMachineImpl interfaces to use …
matinraayai 8715ed6
Created owning and non-owning variants of MMIWP.
matinraayai 832e088
Fixed remaining issues with MMI/MMIWP constructions.
matinraayai cdb9975
Revert back style change.
matinraayai 42c5c73
clang format.
matinraayai 8c213d5
Merge branch 'llvm:main' into mra/make-mmiwp-take-mmi-reference
matinraayai c71cae3
Fixed missing uses of OwningMachineModuleInfoWrapperPass.
matinraayai 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 hidden or 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 hidden or 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 hidden or 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 hidden or 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 hidden or 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 hidden or 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 hidden or 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 hidden or 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 hidden or 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
Oops, something went wrong.
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.
I think we should not have different versions of the pass. We should change wholly change the ownership mode for the pass to not own it.
(Also I've been thinking we should rename MachineModuleInfo. It's really more of a "MachineFunctionMap" or something)
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.
Originally I intended to only have a single version, but the main issue I found was that creating a
MachineModuleInfo
requires any client ofTargetMachine::addPassesToEmitFile
andTargetMachine::addPassesToEmitMC
to be linked againstCodeGen
, which it might not be something they want to do. This only applies to targets that implement codegen, however. All other out-of-tree non-codegen targets are not affected.I will change to my originally intended design if you think it's acceptable to force all
TargetMachine
clients to link againstCodeGen
.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 guess I don't understand what the use case is for this specific pass if you aren't using codegen. MachineModuleInfo, and by extension MachineModuleInfoWrapperPass are a fundamental part of codegen (it is after all just a map of MachineFunction). I would expect for only the owning version to exist, and it to not change the linking requirements of addPassesToEmitFile users
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.
One without MachineModuleInfo is for something else; Owning probably isn't the right name (but neither is MachineModuleInfo)
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 can combine the two passes together into a single
MachineModuleInfoWrapperPass
that looks like the following:This way, there is only a single version of the pass, and it will continue to behave the same way as it did before, while supporting the new functionality.
I'm curious, how does
addPassestoEmitFiles
for the newPM
handles the issue of not owning theMMI
reference? Does it force its users to link against CodeGen?