[PATCH] D46336: [InstCombine] Apply binary operator simplifications to associative/commutative cases.

[Hiroshi Yamauchi via Phabricator via llvm-commits]

yamauchi added a comment.

In https://reviews.llvm.org/D46336#1087866, @spatel wrote:

> In https://reviews.llvm.org/D46336#1087038, @yamauchi wrote:
>
> > In https://reviews.llvm.org/D46336#1085279, @spatel wrote:
> >
> > > I think part of this has already landed with:
> > >  https://reviews.llvm.org/rL331311
> >
> >
> > What's 'this'? I am not clear how https://reviews.llvm.org/rL331311 (partially?) helps with the bitcheck combining this patch is aiming for. Do you mean a similar approach could be taken?
>
>
> I was assuming from the name of this and similar tests:
>  "bit-check-combine1"
>  that 'this' was looking for any-bit-set / any-bit-clear / all-bits-set / all-bits-clear. Maybe the patterns you're looking for don't look like what I am matching though? If I run -instcombine on the first test, it is already substantially reduced...and at that point, it just looks like a problem for -reassociation?
>
>   define i1 @bit-check-combine1(i32 %a, i32 %b) {
>   entry:
>     %0 = and i32 %b, 8
>     %1 = and i32 %b, 16
>     %2 = and i32 %b, 32
>     %3 = and i32 %a, 7   <--- we got lucky on this one and found the reduction
>     %4 = or i32 %3, %0
>     %5 = or i32 %4, %1    <--- reassociate the 'or' operands, so we can factor out the mask ops
>     %6 = or i32 %5, %2
>     %7 = icmp eq i32 %6, 0
>     ret i1 %7
>   }
>  
>


https://reviews.llvm.org/rL331311 seemed about folding a chain of or-shifts. How does it directly help with bit checks? That was my question.

As my above comment at Thu, May 3, 3:12 PM went, this patch doesn't look for the bit check pattern (or any other pattern) but indirectly promotes the bit check combining by triggering the instcombine folding for the associative/commutative positions of binops. The actual bit check combining is handled by foldLogOpOfMaskedICmps().

Based on the following description of the reassociation pass (-reassociation), I'm not sure if it's an issue specifically with it.

https://llvm.org/docs/Passes.html#reassociate-reassociate-expressions

> This pass reassociates commutative expressions in an order that is designed to promote better constant propagation, GCSE, LICM, PRE, etc.
> 
> For example: 4 + (x + 5) ⇒ x + (4 + 5)
> 
> In the implementation of this algorithm, constants are assigned rank = 0, function arguments are rank = 1, and other values are assigned ranks corresponding to the reverse post order traversal of current function (starting at 2), which effectively gives values in deep loops higher rank than values not in loops.


Repository:
  rL LLVM

https://reviews.llvm.org/D46336