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

Filipp Zhinkin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Dec 7 11:11:56 PST 2021


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();
----------------
fzhinkin wrote:
> 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.
> 
`MergeConcat`'s `CmpZero` case will continue to work and there is no easy way to exclude cases that could be handled by both `optimizeSetCCOfExpandedShift` and `MergeConcat`. So I think it does make sense to apply `optimizeSetCCOfExpandedShift` after `MergeConcat` and only when types legalization is complete. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111530



More information about the llvm-commits mailing list