-
Notifications
You must be signed in to change notification settings - Fork 556
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
Integrate llvm-project @4f3c9dabecc6074f8455ca23ba70020d5c556e63 #17827
Conversation
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
Signed-off-by: yzhang93 <zhyuhang88@gmail.com>
…i] expose elideLargeResourceString (#98050) (Brendan Hansknecht on 2024-07-08 14:12:49 -0700) (29 of 31) Signed-off-by: yzhang93 <zhyuhang88@gmail.com>
Signed-off-by: yzhang93 <zhyuhang88@gmail.com>
9393964
to
a99394c
Compare
Signed-off-by: hanhanW <hanhan0912@gmail.com>
linalg::ControlPropagationFn control = [](OpOperand *opOperand) -> bool { | ||
Operation *producer = opOperand->get().getDefiningOp(); | ||
Operation *consumer = opOperand->getOwner(); | ||
return !getLoweringConfig(producer) || !getLoweringConfig(consumer); |
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.
@qedawkins is the change correct? Do we check both operations, or do we only check producer or consumer?
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 want &&
because one of the operations will be a pack
/unpack
and the other will be the to-be-packed op.
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.
LGTM with the one amendment Hanhan asked about
linalg::ControlPropagationFn control = [](OpOperand *opOperand) -> bool { | ||
Operation *producer = opOperand->get().getDefiningOp(); | ||
Operation *consumer = opOperand->getOwner(); | ||
return !getLoweringConfig(producer) || !getLoweringConfig(consumer); |
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 want &&
because one of the operations will be a pack
/unpack
and the other will be the to-be-packed op.
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.
The changes look good to me. I can send a follow-up if Quinn has some comments. The only concern is about the benchmark result.
Sounds good, no need to block on my comment because I see that CI is being finicky and it's a path we don't hit anywhere yet. |
This is a follow-up from the integrate comment: #17827 (comment) The comment was not addressed in the integrate PR because the CI was not stable. Some runners were off, and we decided to land the PR and sent a follow-up later. See https://discord.com/channels/689900678990135345/1080178290188374049/1260330876651307090 for some details.
This is a follow-up from the integrate comment: #17827 (comment) The comment was not addressed in the integrate PR because the CI was not stable. Some runners were off, and we decided to land the PR and sent a follow-up later. See https://discord.com/channels/689900678990135345/1080178290188374049/1260330876651307090 for more details.
This is a follow-up from the integrate comment: iree-org#17827 (comment) The comment was not addressed in the integrate PR because the CI was not stable. Some runners were off, and we decided to land the PR and sent a follow-up later. See https://discord.com/channels/689900678990135345/1080178290188374049/1260330876651307090 for more details.
This is a follow-up from the integrate comment: iree-org#17827 (comment) The comment was not addressed in the integrate PR because the CI was not stable. Some runners were off, and we decided to land the PR and sent a follow-up later. See https://discord.com/channels/689900678990135345/1080178290188374049/1260330876651307090 for more details. Signed-off-by: saienduri <saimanas.enduri@amd.com>
Reverted commits: