[Bug middle-end/111446] New: genmatch should warn/error out on recusive match patterns

[Bug middle-end/111446] New: genmatch should warn/error out on recusive match patterns

[pinskia at gcc dot gnu.org]

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

            Bug ID: 111446
           Summary: genmatch should warn/error out on recusive match
                    patterns
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: internal-improvement
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: pinskia at gcc dot gnu.org
          Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

After PR 111442 and PR 111435, I figure we should warn (or error out) about the
case where a match recusively uses itself as that will cause issues with VN and
almost always generate an infinite loop.

[Bug middle-end/111446] genmatch should warn/error out on recusive match patterns

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-09-17
             Status|UNCONFIRMED                 |ASSIGNED

[Bug middle-end/111446] genmatch should warn/error out on recusive match patterns

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note originally I intended to have (match (...)) inlined in the match IL
itself,
so any such checking should not only check for direct recursion but indirect
as well - all SCCs are unsupported.

(match (one @0)
 (negate @0))

(match (zero @0)
 (negate (one @0)))

(match (one @0)
 (negate (zero @0)))

[Bug middle-end/111446] genmatch should warn/error out on recusive match patterns

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Andrew Pinski <pinskia@gcc.gnu.org>:

https://gcc.gnu.org/g:7ea501d3ea698e1c845fb61e3487f4cd949e6253

commit r14-4114-g7ea501d3ea698e1c845fb61e3487f4cd949e6253
Author: Andrew Pinski <apinski@marvell.com>
Date:   Sun Sep 17 11:20:36 2023 -0700

    MATCH: Make zero_one_valued_p non-recursive fully

    So it turns out VN can't handle any kind of recursion for match. In this
    case we have `b = a & -1` and we try to match a as being zero_one_valued_p
    and VN returns b as being the value and we just go into an infinite loop at
    this point.

    OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

    Note genmatch should warn (or error out) if this gets detected so I filed
PR 111446
    which I will be looking into next week or the week after so we don't run
into
    this issue again.

            PR tree-optimization/111442

    gcc/ChangeLog:

            * match.pd (zero_one_valued_p): Have the bit_and match not be
            recursive.

    gcc/testsuite/ChangeLog:

            * gcc.c-torture/compile/pr111442-1.c: New test.

[Bug middle-end/111446] genmatch should warn/error out on recusive match patterns

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> Note originally I intended to have (match (...)) inlined in the match IL
> itself,
> so any such checking should not only check for direct recursion but indirect
> as well - all SCCs are unsupported.
> 
> (match (one @0)
>  (negate @0))
> 
> (match (zero @0)
>  (negate (one @0)))
> 
> (match (one @0)
>  (negate (zero @0)))

Yes I guess the easiest/best way to implement this is to walk the predicate
definitions to make sure they don't loop back.