[PATCH] D155412: [ConstraintElim] Add facts implied by MinMaxIntrinsic
Yingwei Zheng via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Jul 18 04:14:48 PDT 2023
dtcxzyw added inline comments.
================
Comment at: llvm/lib/Transforms/Scalar/ConstraintElimination.cpp:788
+ if (isa<MinMaxIntrinsic>(&I)) {
+ WorkList.push_back(FactOrCheck::getFact(DT.getNode(&BB), &I));
+ continue;
----------------
fhahn wrote:
> fhahn wrote:
> > nikic wrote:
> > > I don't think this is right. It does not correctly represent where the fact will apply. This should be rooted at a branch/assume, just like the normal icmp handling.
> > >
> > > Likely the fact in the worklist should just be the icmp, and we should only handle the min/max when adding it to the constraint system.
> > @dtcxzyw could you add test cases that would be incorrectly simplified? Something like doing a `umin` in one block, then doing a check that can be simplified with the facts that get added and only later use the result of the umin in a compare.
> Hmm not sure if it is actually possible to show a miscompile with the above.
>
> I think one way to handle this would be to inject I <= I->getOperand(0), I <= I->getOperand(1) as facts here.
>
> That leaves the question on how to best synthesize such conditions here. The simplest way would be to create temporary ICMP instructions. Not sure what other people think about that though and if we need a more local/lightweight representation for conditions.
I think the triple `(ICmpInst::Predicate Pred, Value* Lhs, Value* Rhs)` is better than `(ICmpInst* Inst, bool Not)` to represent a fact.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D155412/new/
https://reviews.llvm.org/D155412
More information about the llvm-commits
mailing list