[PATCH] D52001: [InstCombine] Inefficient pattern for high-bits checking 2 (PR38708)

Roman Lebedev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 13 11:52:59 PDT 2018


lebedev.ri added a comment.

In https://reviews.llvm.org/D52001#1233768, @spatel wrote:

> I was wondering if it would be easier to read if we swapped everything as a first step, so something like this in the existing code:
>
>   // We want X to be the icmp's second operand, so swap if not.
>   Value *Cmp0 = Cmp.getOperand(0), *X = Cmp.getOperand(1);
>   ICmpInst::Predicate Pred = Cmp.getPredicate(), NewPred;
>   if (match(X, m_OneUse(m_Shl(m_One(), m_Value())))) {
>     std::swap(Cmp0, X);
>     Pred = Cmp.getSwappedPredicate();
>   }
>   Value *Y;
>   if (!match(Cmp0, m_OneUse(m_Shl(m_One(), m_Value(Y)))))
>     return nullptr;
>   if (Pred == ICmpInst::ICMP_ULE) NewPred = ICmpInst::ICMP_NE;
>   else if (Pred == ICmpInst::ICMP_UGT) NewPred = ICmpInst::ICMP_EQ;
>   else return nullptr;
>   
>   


I'm not sure.
I think we really should have two separate matches, and two `switch()`es.
Else i think we may use the wrong predicate..
Also, i *think* i will add one/two patterns to this new matcher (less canonical variants with extra uses),
so specifying the pattern twice seems sub-par.

> It's mostly a matter of taste, but there's a subtle logic difference: what if both sides of the icmp match the shift pattern?
> 
>   define i1 @p0(i8 %shamt0, i8 %shamt1) {
>     %t0 = shl i8 1, %shamt0
>     %t1 = shl i8 1, %shamt1
>     %r = icmp ugt i8 %t0, %t1
>     ret i1 %r
>   }
>   
> 
> 
> With the current code, it gets transformed to:
> 
>   define i1 @p0(i8 %shamt0, i8 %shamt1) {
>     %t1 = shl i8 1, %shamt1
>     %t1.highbits = lshr i8 %t1, %shamt0
>     %r = icmp eq i8 %t1.highbits, 0
>     ret i1 %r
>   }
>   
> 
> 
> It should be reduced:
> 
>   %t0 = shl i8 1, %shamt0
>   %t1 = shl i8 1, %shamt1
>   %r = icmp ugt i8 %t0, %t1
>   =>
>   %r = icmp ugt i8 %shamt0, %shamt1
>    
> 
> I don't think we need to hold up this patch for that, but maybe it changes the way we want to implement it?

I acknowledge that there is some problem when we have the same/similar pattern on the both sides,
i have thought about it a bit (https://reviews.llvm.org/rL342076), but i don't have anything concrete on that.


Repository:
  rL LLVM

https://reviews.llvm.org/D52001





More information about the llvm-commits mailing list