-
Notifications
You must be signed in to change notification settings - Fork 572
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
Add more tests and KillInst() to DefUseManager #347
Closed
Closed
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
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
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 don't think we need this map at all. It just guards clearing of the def+uses of an instruction. But the clear method should be resilient to the case where the instruction hasn't been analyzed before.
?!
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.
There may be four cases (depends on whether we want to make ir::Instruction to be immutable later) we need to differentiate:
For case 1), the desired result is that, the def-use records of the analyzed operands should be +1 to have the new added instruction as their new uses.
For case 2), the desired result is that, the original result_id defining instruction should be cleared first, then the new added instruction can update the records for the involved operands. This is a -1 followed by +1 for the operands.
For case 3), we should -1 first then +1, same as a new instruction with existing result id.
For case 4), we should also -1 first then +1, same as a new instruction with existing result id, but this is different with case 1).
To differentiate the four cases we have two options:
a) See if the instruction has a result id.
If the instruction has a result id, clear internal records for the id, then analyze the new instruction. Otherwise analyze the new instruction directly. But this way we can not differentiate case 1 and case 4. We will -1 for the operands in case 1.
b) Use a set to hold all the analyzed instructions.
If the instruction has been analyzed, clear its record first.
If the result id has been analyzed before, clear its def_id record also.
Add record for the given instruction as if it is a new instruction.
Actually the fundamental solution to this hassle is to use instruction* instead of id(uint32_t) for the internal maps then we can unify the behavior. But that may changed the structure a lot. This is the reason why we need such a set here.
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.
My point was that asking to remove a use from an instruction should be a no-op if that use is not actually recorded. Then your cases 1 and 4 don't need to be distinguished.
But I see there is complexity in having instruction's operands already be analyzed from the definer's perspective, and then you try to analyze the user's perspective. I have a headache and I'd like a second opinion on this.
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.
Oh, yes, you are right. If the target instruction is really a new instruction, ClearInst() won't change the def-use records of the target instruction's operand id.
I missed the "is same instruction" check when erasing use records.