-
Notifications
You must be signed in to change notification settings - Fork 53
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
Fixing DomainMap::areAllTargetIdsCoveredBy
to handle broadcast to non-root IDs
#3655
Merged
Merged
Changes from all commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
bd469b4
WIP
jjsjann123 6d09536
test added
jjsjann123 3c38b0f
wip
jjsjann123 89bafe3
fixing test
jjsjann123 2a23470
comment
jjsjann123 9079c01
Merge remote-tracking branch 'origin/main' into HEAD
jjsjann123 69a29e7
adding comment per review request
jjsjann123 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
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.
This is the patch. I added another call to
get_source_iter_domain({concrete_id_out})
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.
So, for a given logical ID, we take its source IDs, then for each source ID, take the source IDs of its concrete ID. I understand it would work for the repro, but I wonder why it would need to take source IDs twice. For example, would it work if we took first the concrete ID of a logical ID and then its source IDs?
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 need to take the first
source ID
of the logical ID for the pad example to work, i.e. in the comment above from line 252 - 258.We want to have T2 as the reference TV and we want to be able to map T3 to T2. For i9 in T3. I wanted to first map to source ID, so it can be map to b0, which would concretize to i1.
So my naive justification of going through source IDs twice is that: the first source ID call allows us to trace back to broadcast IDs that went through a resize; while the second source ID calls allow us to resolve transformations on the concrete IDs.
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'm fine with this PR as long as #3653 is fixed, but I'm feeling there's something not quite right here, probably because
T2
andT3
shouldn't be actually mapped. They could have completely different sizes, and neitherT2
norT3
should not be considered representative.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.
#3576 (comment)
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 agree with you.
We have some existing tests that asserts the behavior, which might not be what we would want to support moving forward.
I'll update the comment here per suggestion and merge this PR as-is just so we can patch the issue.
Meanwhile, I think the case where you are making is that, we shouldn't map through PERMISSIVE mapping in the first place here. I'll start a draft PR with that to see how many tests are affected. We can discuss what's the next step then.
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'm not sure if it's something we should worry about at this moment. No test should fail functionally since it's a segmentation issue. It would be just a performance difference, but unless we have a benchmark that has this particular pattern, it doesn't make much sense to discuss what we should do.