[Bug middle-end/108990] New: Too restrictive precision check in fold and simplify pattern for PR70920

[Bug middle-end/108990] New: Too restrictive precision check in fold and simplify pattern for PR70920

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108990

            Bug ID: 108990
           Summary: Too restrictive precision check in fold and simplify
                    pattern for PR70920
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

While experimenting with a new gimple pass we noticed that pr70920.c is
sensitive on order of substitutions made.  If 0 is propagated first into if
stmt, match and simplify fails to simplify the conditional since it compares
pointer type 0 with integer converted to pointer type.
TYPE_PRECISION of int is 32.

(for cmp (ne eq)
 (simplify
  (cmp (convert @0) INTEGER_CST@1)
  (if (((POINTER_TYPE_P (TREE_TYPE (@0))
         && !FUNC_OR_METHOD_TYPE_P (TREE_TYPE (TREE_TYPE (@0)))
         && INTEGRAL_TYPE_P (TREE_TYPE (@1))
         /* Don't perform this optimization in GENERIC if @0 has reference
            type when sanitizing.  See PR101210.  */
         && !(GENERIC
              && TREE_CODE (TREE_TYPE (@0)) == REFERENCE_TYPE
              && (flag_sanitize & (SANITIZE_NULL | SANITIZE_ALIGNMENT))))
        || (INTEGRAL_TYPE_P (TREE_TYPE (@0))
            && POINTER_TYPE_P (TREE_TYPE (@1))
            && !FUNC_OR_METHOD_TYPE_P (TREE_TYPE (TREE_TYPE (@1)))))
       && TYPE_PRECISION (TREE_TYPE (@0)) == TYPE_PRECISION (TREE_TYPE (@1)))
   (cmp @0 (convert @1)))))

So last conditional is false (32 and 64)

In this adjusted testcase:
#include <stdint.h>

void f1();
void f2();

void
foo (int a)
{
  int *b = (int *)a;
  if (b == (void *)0)
    {
      f1 ();
    }
}

the unnecessary cast survives to forwprop while it chould be caught by cpp1

[Bug middle-end/108990] Too restrictive precision check in fold and simplify pattern for PR70920

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108990

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=70920
   Last reconfirmed|                            |2023-03-02
           Severity|normal                      |enhancement

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
There are other patterns which handle different precision integeral types
though.

e.g.
match.pd:5780
     /* If possible, express the comparison in the shorter mode.  */
     (if ((cmp == EQ_EXPR || cmp == NE_EXPR
           || TYPE_UNSIGNED (TREE_TYPE (@0)) == TYPE_UNSIGNED (TREE_TYPE (@00))
           || (!TYPE_UNSIGNED (TREE_TYPE (@0))
               && TYPE_UNSIGNED (TREE_TYPE (@00))))
          && (types_match (TREE_TYPE (@10), TREE_TYPE (@00))
              || ((TYPE_PRECISION (TREE_TYPE (@00))
                   >= TYPE_PRECISION (TREE_TYPE (@10)))
                  && (TYPE_UNSIGNED (TREE_TYPE (@00))
                      == TYPE_UNSIGNED (TREE_TYPE (@10))))
              || (TREE_CODE (@10) == INTEGER_CST
                  && INTEGRAL_TYPE_P (TREE_TYPE (@00))
                  && int_fits_type_p (@10, TREE_TYPE (@00)))))
      (cmp @00 (convert @10))

I wonder if the pattern for PR 70920 should be combined with the above one and
fixed up.

[Bug middle-end/108990] Too restrictive precision check in fold and simplify pattern for PR70920

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108990

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Consolidating these kind of duplicates would be nice.  Note in this particular
case we should order the more specific pattern earlier (diagnosing that with
-v would be nice).

Implementing order preserving differently, for example by expressing
'A must be matched before B' explicitely would be a good improvement as well.
If you add -v to the genmatch command-line you'll see 273 cases where we
forcefully re-start matching because of intermediate "more specific" patterns.