Re: [PATCH][RFC] Automatized pattern matching

[Zack Weinberg <zack at codesourcery dot com>]

Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz> writes:

> Hello,
>
> as someone mentioned on gcc summit, quite a lot of big conditions in gcc
> is in fact a pattern matching on rtl expressions, that probably cannot
> be expressed in a more clear way in c directly.
>
> What we could however do is to use a language more suited to this task
> to describe the patterns and to translate them into c automatically.
> The patch below shows a simple implementation of this idea (for
> technical details see comments in pattern.c); it for example allows you
> to write
>
>   if (MATCH_RTX ("(const (plus $base const_int@1))", addr))
>     offset = INTVAL (_match1);
>
> instead of (real piece of code from cse.c)
>
>   if (GET_CODE (addr) == CONST && GET_CODE (XEXP (addr, 0)) == PLUS
>       && GET_CODE (XEXP (XEXP (addr, 0), 1)) == CONST_INT)
>     {
>       base = XEXP (XEXP (addr, 0), 0);
>       offset = INTVAL (XEXP (XEXP (addr, 0), 1));
>     }

It's great that you've done this.  I have just a few suggestions:

* The use of file-static variables for match results seems suboptimal
  to me.  I would suggest that you instead require all such variables
  to be declared by the programmer.  You can keep the $digit notation,
  with the match variables having the same names you gave them.
  (A twisted alternate idea: "auto TYPE foo;" at file scope is
  currently a hard error, and I think a constraint violation; we could
  make it mean 'implicitly declare this variable at function scope in
  any function that uses it' as an extension.)

* I find the !{} notation for "any RTX code" confusing.  Maybe a *
  could mean the same thing?

* It might be useful to allow selection by rtx classes, you could
  allow, say, '<'

* Is there any reason to have different symbols for constrained and
  unconstrained variable assignment?  Why not allow
  "(const (plus $base const_int$1))"?  Or
  "(const (plus @base const_int@1))", which is arguably more readable.

* You might see if some of the gengtype parser can be reused for this.

* Some of the places where you have a "MATCH_RTX (...) && ..." could
  become just a MATCH_RTX expression if you had the ability to match
  flags.  For instance,

  if (MATCH_RTX ("(use mem@0)", x)
      && !MEM_VOLATILE_P (_match0))

  becomes

  if (MATCH_RTX ("(use mem/v@0)", x))

  The trouble with this idea is that the /x names for the qualifiers
  are heavily overloaded.  It might not be a net win.  Ugh.

zw