[PATCH] D111530: [TargetLowering] Optimize expanded SRL/SHL fed into SETCC ne/eq 0

[Filipp Zhinkin via Phabricator via llvm-commits]

fzhinkin added inline comments.


================
Comment at: llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp:4153
       // all bits clear: (X | (Y<<32)) ==  0 --> (X | Y) ==  0
       // all bits set:   (X | (Y<<32)) == -1 --> (X & Y) == -1
       bool CmpZero = N1C->getAPIntValue().isZero();
----------------
RKSimon wrote:
> fzhinkin wrote:
> > fzhinkin wrote:
> > > RKSimon wrote:
> > > > This is doing something pretty similar, its more limited to the 'concat' pattern but handles the -1 'allbits' case as well.
> > > Are you suggesting to extract and reuse code common to both optimizations or to support `-1` in `optimizeSetCCOfExpandedShift`?
> > It does not make sense to support `-1` in `optimizeSetCCOfExpandedShift` because a shifted value (the method support only logical shifts) is never equal to `-1`.
> > 
> > For me it seems like "concat" optimization and `optimizeSetCCOfExpandedShift`  are not so similar. "concat" opt merges OR arms in place, but `optimizeSetCCOfExpandedShift` eliminate shift pairs that are scattered among the tree and the whole tree should be scanned before final OR reduction is applied.
> OK - what about the CmpZero case - is that redundant dead code now?
CmpZero case is redundant only if `Y`'s type was lowered to a pair of values having narrower type (`X` and `Y` are `i64` and comp. target is `armv7`).

However, concat optimization still works for following cases not supported in `optimizeSetCCOfExpandedShift`:
- `X` and `Y` whose type was legal (`X` and `Y` are `i64`,  `x86_64` is the target);
- `X` and `Y` are vectors.

I did not support vector types in `optimizeSetCCOfExpandedShift` because it seems impossible to get a DAG with appropriate shape during vectors legalization.



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111530/new/

https://reviews.llvm.org/D111530