[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