When running my expanded version of misc-redundant-expression on LLVM
source, following potential problems were found (after filtering false
positives):

llvm/utils/TableGen/CodeGenDAGPatterns.cpp:483:35: warning: both sides of
operator are equivalent [misc-redundant-expression]
if (any_of(S, isIntegerOrPtr) && any_of(S, isIntegerOrPtr)) {

This was attempted at https://reviews.llvm.org/D69741 but hit issues with it causing timeouts on some buildbots that were never resolved.

RISC V backend causes build problems if we fix this code :(

llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp:3875:34: warning: 'true' and
'false' expressions are equivalent [misc-redundant-expression]
return UseSPE ? PPC::PRED_LE : PPC::PRED_LE;
^
llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp:3878:34: warning: 'true' and
'false' expressions are equivalent [misc-redundant-expression]
return UseSPE ? PPC::PRED_GT : PPC::PRED_GT;

Justin - these duplicates were added at rG2c4620ad57b8 - please can you take a look?

llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp:3875:34: warning: 'true' and
'false' expressions are equivalent [misc-redundant-expression]
return UseSPE ? PPC::PRED_LE : PPC::PRED_LE;
^
llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp:3878:34: warning: 'true' and
'false' expressions are equivalent [misc-redundant-expression]
return UseSPE ? PPC::PRED_GT : PPC::PRED_GT;

Justin - these duplicates were added at rG2c4620ad57b8 - please can you take
a look?

Obvious redundancy is obviously redundant. That set of changes was pretty mechanical. I'll remove the redundancies.

Reset for someone else to take the non-SPE redundancies.

PowerPC bit was fixed in rGb8dc54cf39b

llvm/tools/llvm-exegesis/lib/MCInstrDescView.cpp:122:24: warning: expression
is redundant [misc-redundant-expression]
assert(TiedToIndex == -1 ||

Fixed in rG83d0db59d6ff

clang-tools-extra/clang-tidy/readability/BracesAroundStatementsCheck.cpp:45:
17: warning: expression is redundant [misc-redundant-expression]
if (TokKind == tok::NUM_TOKENS || TokKind != tok::comment)

Fixed in rG17785cc7a105

                             ^

polly/lib/Support/ISLTools.cpp:67:23: warning: both sides of operator are
equivalent [misc-redundant-expression]
for (auto i = Dims1 - Dims1; i < Dims1; i += 1)
^
polly/lib/Support/ISLTools.cpp:69:23: warning: both sides of operator are
equivalent [misc-redundant-expression]
for (auto i = Dims2 - Dims2; i < Dims2; i += 1) {

Tobias - please would you be able to deal with these?

AFAIK the initial values should be zero both times. Michael Kruse wrote the code initially. @​Michael, do you recall why there are these surprising differences?

Btw., Alex, this is a great new warning. Thanks for pointing it out.

Fixed in https://reviews.llvm.org/rG84c934a5cbe2fdb7e0bb61a94e4dfa5e6cc3e0b2

The idiom

for (auto i = n - n; i < n; i += 1)

was intended to automatically derive the type of i from n (signed/unsigned int) and avoid the 'mixed signed/unsigned comparison' warning. However, almost-always-auto was never used in the LLVM coding style (although we used it in Polly for some time) and I did never intended to use this idiom upstream.

Thanks Michael

When running my expanded version of misc-redundant-expression on LLVM
source, following potential problems were found (after filtering false
positives):

llvm/utils/TableGen/CodeGenDAGPatterns.cpp:483:35: warning: both sides of
operator are equivalent [misc-redundant-expression]
if (any_of(S, isIntegerOrPtr) && any_of(S, isIntegerOrPtr)) {

Reopened, we still need to fix this (annoying) one.

*** Bug llvm/llvm-bugzilla-archive#47032 has been marked as a duplicate of this bug. ***

The first redundancy is a bug, is it not?

llvm/utils/TableGen/CodeGenDAGPatterns.cpp:483:35: warning: both sides of operator are equivalent [misc-redundant-expression]
if (any_of(S, isIntegerOrPtr) && any_of(S, isIntegerOrPtr)) {
^
The second any_of() should be testing B.

Yes, bug. But if you fix it, riscv backend will break.

Yes, bug. But if you fix it, riscv backend will break.

https://reviews.llvm.org/D69741 tried to fix it but RISCV then exploded :-(

Is it worth trying to investigate what's going on? If not, I could at least remove the redundant test and add a comment.

Is it worth trying to investigate what's going on? If not, I could at least
remove the redundant test and add a comment.

I'd much prefer to see this fixed rather than dodged. The issue appeared to be a RISCV sext_inreg patterns not matching properly - D69741 has more details.

Okay, I'll take a look.

This seems to be an issue with HwModes. The patterns that are failing are RV64 only patterns. I think the hangs are occuring while trying to solve for RV32 mode where they have no solution.

Patch
This patch appears to fix the hang and passes check-llvm. I did not check the effect on any generated files.

The basic idea is to suppress the change detection on small when small came from a temporary VT list rather than a real operand. Since we always create a new temporary VT list, we'll keep clearing it over and over again. If that keeps getting reported as a change we'll never terminate.

Craig - what is the status of your proposed patch?

Copied to phab here https://reviews.llvm.org/D111502

The CodeGenDAGPatterns.cpp redundancy has been fixed in aefaf16

Is anything else still open here?

Resolving - all the other expressions had already been addressed. Thanks Craig!

mentioned in issue llvm/llvm-bugzilla-archive#47032

mentioned in issue #51462