Sometimes we get back a full ssa name when looking up the comparison of the GIMPLE_COND
rather than a predicate. We then want to lookup the `val != 0` for the predicate.
Note this might happen with other boolean assignments and COND_EXPR but I am not sure
if it is as important; I have not found a testcase yet.
Bootstrapped and tested on x86_64-linux-gnu.
PR tree-optimization/117414
gcc/ChangeLog:
* tree-ssa-sccvn.cc (process_bb): Lookup
`val != 0` if got back a ssa name when looking the comparison.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/fre-predicated-4.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
--- /dev/null
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+/* PR tree-optimization/117414 */
+
+/* Fre1 should figure out that `*aaa != 0`
+ For f0 and f1. */
+
+
+void foo();
+int f0(int *aaa, int j, int t)
+{
+ int b = *aaa;
+ if (b == 0 || t == 1)
+ return 0;
+ for(int i = 0; i < j; i++)
+ {
+ if (!*aaa) foo();
+ }
+ return 0;
+}
+
+int f1(int *aaa, int j, int t)
+{
+ int b = *aaa;
+ if (b == 0)
+ return 0;
+ if (t == 1)
+ return 0;
+ for(int i = 0; i < j; i++)
+ {
+ if (!*aaa) foo();
+ }
+ return 0;
+}
+
+/* { dg-final { scan-tree-dump-not "foo " "optimized" } } */
+/* { dg-final { scan-tree-dump "return 0;" "optimized" } } */
val = vn_nary_op_lookup_pieces (2, gimple_cond_code (last),
boolean_type_node, ops,
&vnresult);
+ /* Got back a ssa name, then try looking up `val != 0`
+ as it might have been recorded that way. */
+ if (val && TREE_CODE (val) == SSA_NAME)
+ {
+ ops[0] = val;
+ ops[1] = build_zero_cst (TREE_TYPE (val));
+ val = vn_nary_op_lookup_pieces (2, NE_EXPR,
+ boolean_type_node, ops,
+ &vnresult);
+ }
/* Did we get a predicated value? */
if (! val && vnresult && vnresult->predicated_values)
{