On 9/5/25 12:44 AM, Richard Biener wrote:
On Fri, Sep 5, 2025 at 1:50 AM Andrew Pinski
<andrew.pin...@oss.qualcomm.com> wrote:

SRA likes to create VCE<bool>(a) when it comes to bool. This confuses
a few different passes including jump threading and uninitialization
warning. This removes the VCE in one case where it will help.
Values outside of 0/1 with the VCE will produce undefined code so
removing the VCE is always fine as we go from undefined to well defined
and not introduce new undefined code.

This fix is like what was done for PR 80635 but not depending on the VRP to
do the work so it is fixed at -O1 too.

Bootstrapped and tested on x86_64-linux-gnu.

         PR tree-optimization/105749
         PR tree-optimization/80635

gcc/ChangeLog:

         * match.pd (`VCE<bool>(a) ==\!= 0`): New pattern.

gcc/testsuite/ChangeLog:

         * g++.dg/warn/pr80635-3.C: New test.
         * g++.dg/warn/pr80635-4.C: New test.

Signed-off-by: Andrew Pinski <andrew.pin...@oss.qualcomm.com>
---
  gcc/match.pd                          | 10 ++++++
  gcc/testsuite/g++.dg/warn/pr80635-3.C | 47 +++++++++++++++++++++++++++
  gcc/testsuite/g++.dg/warn/pr80635-4.C | 32 ++++++++++++++++++
  3 files changed, 89 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/warn/pr80635-3.C
  create mode 100644 gcc/testsuite/g++.dg/warn/pr80635-4.C

diff --git a/gcc/match.pd b/gcc/match.pd
index b1d7a3a1b73..954e52d9562 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -2359,6 +2359,16 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
    (bit_not (bit_not @0))
    (non_lvalue @0))

+/* VCE<bool>(a) ==/!= false -> a ==/!= 0.
+   This is done as SRA likes to create VCE for boolean accesses
+   and it helps code gneration and uninitialized variable warnings.  */

But it loses information?  The reverse, VCE<int>(a) with a bool 'a'
would gain.  So I don't quite understand the idea behind this pattern.
Isn't the problem in uninit/jump threading instead?
I thought we decided we didn't want to do this (transform the IL to elide the V_C_E) a while back and instead we wanted the optimizers to see through the V_C_E? It's a vague memory, so take it with some skepticism.

Jeff

Reply via email to