[PATCH] D159499: [InstCombine] Fold or(phi1,phi2) into or(icmp1,icmp2)
Noah Goldstein via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Sep 19 13:36:47 PDT 2023
goldstein.w.n added inline comments.
================
Comment at: llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp:2030
+ m_ICmp(EqPred, m_Specific(operand->get()), m_Zero())) &&
+ EqPred == ICmpInst::ICMP_NE))))
+ return nullptr;
----------------
bipmis wrote:
> goldstein.w.n wrote:
> > This seems very much so like a DAG type fold where you are basing the decision on existing expressions.
> > `phi` doesn't exist in backend (dagcombiner) so its a bit tricky.
> > @nikic, any place this can be put where it doesn't req iterating the use-list?
> >
> > generally in instcombine we get our duplication by just blindly canoniclizing to a standard format.
> >
> > Is there a regression if you blindly do the transform?
> I am seeing quite some benefit with this Transform as we are able to reuse instructions which happens to be the other use of phi.
> However just the direct transform
> or(i64 a,i64 b) -> or((icmp ne a ,0), (icmp ne b ,0)) is expensive. On the contrary the reverse is true in InstCombine.
>
> I can check if the transform or(i64 phia,i64 phib) regresses.
There are a lot of folds that we can do / improve if we optimized around "what exists". If there is a place for such folds (prior to DAGCombiner) that would want this to be moved there. Maybe nikic has an idea about that.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D159499/new/
https://reviews.llvm.org/D159499
More information about the llvm-commits
mailing list