-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[LICM] Preserve Disjoint flag on OR when hoisting. #140266
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2877,6 +2877,13 @@ static bool hoistBOAssociation(Instruction &I, Loop &L, | |
if (auto *I = dyn_cast<Instruction>(Inv)) | ||
I->setFastMathFlags(Intersect); | ||
NewBO->setFastMathFlags(Intersect); | ||
} else if (Opcode == Instruction::Or) { | ||
bool Disjoint = cast<PossiblyDisjointInst>(BO)->isDisjoint() && | ||
cast<PossiblyDisjointInst>(BO0)->isDisjoint(); | ||
// If `Inv` was not constant-folded, a new Instruction has been created. | ||
if (auto *I = dyn_cast<PossiblyDisjointInst>(Inv)) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This cast is fragile; it only works under certain assumptions about what the IRBuilder will not fold. Maybe use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Currently this uses the default ConstantFolder, which should be fine, as we either get a constant or the required. OR instruction. This is similar to the code for the other cases above. Is there any particlar case you are thinking where this would be too fragile? I can imagine that we would have to be more careful if the folder could fold the op to an existing other IR value, in which case we may end up setting the disjoint flags on a different OR than we intended. But I don't think that can be the case with the ConstantFolder. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's not actually wrong with ConstantFolder, I guess, but the interaction is pretty subtle. I've seen similar-looking code cause real issues. Maybe it's enough to spell out that it's using ConstantFolder, and why it's getting used? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks, added the same comment as we have above for the ADD/MUL case. |
||
I->setIsDisjoint(Disjoint); | ||
cast<PossiblyDisjointInst>(NewBO)->setIsDisjoint(Disjoint); | ||
} | ||
|
||
BO->replaceAllUsesWith(NewBO); | ||
|
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 block of code seems like something we should have a helper for. As a follow up, maybe factor something out of other places we do reassociation?
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.
Actually, unless I'm missing something, Reassociate.cpp has the same problem of dropping disjoint flags. Note that there is the existing OverflowTracking helper, which might serve as a starting place for the API.