[PATCH][RFC] Automatized pattern matching

[Zack Weinberg]

Responding to several messages at once...

>>   if (MATCH_RTX ("(use mem@0)", x)
>>       && !MEM_VOLATILE_P (_match0))
>
> this is _not_ mem_volatile_p ...
>
>>   becomes
>>
>>   if (MATCH_RTX ("(use mem/v@0)", x))
>
> ... and this looks like volatile.  So, also a negation for matching
> unset flags would be needed.  But it could be usefull indeed.
>
>>   The trouble with this idea is that the /x names for the qualifiers
>>   are heavily overloaded.  It might not be a net win.  Ugh.

Bah, I missed the negation on the first read.

While out for a walk I thought of a better approach which solves both
problems at once:

  if (MATCH_RTX ("(use mem/!MEM_VOLATILE_P@0)"))

Here the ! is optional, indicating negation, and MEM_VOLATILE_P can be
any one-argument macro or function visible at this point.  This is
much more flexible and does not run afoul of the overloading of the /x
names.  It can be used with anything, not just flags; consider

       if (MATCH_RTX ("(!{} reg@0)", x)
           && ! REGNO_QTY_VALID_P (REGNO (_match0)))

(from the original patch) which could become

#define REG_QTY_VALID_P(X) REGNO_QTY_VALID_P(REGNO(X))
...
       if (MATCH_RTX ("(!{} reg/REG_QTY_VALID_P@0)"))

I am unsure whether 

       if (MATCH_RTX ("(!{} reg@0/REG_QTY_VALID_P)"))

would be better notation - opinions solicited.

Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz> writes:
>> * 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.
>
> I have considered this; I have done it this way in order to make the
> life easier and not to have to explicitly declare the temporary variables.
> It is of course suboptimal, but on many places it does not matter and
> on the performance critical ones you can always use a local variable.

I am thinking not so much of performance, as of potential conflicts
between users of these static variables.  If for instance someone
writes

  if(MATCH_RTX("(plus $0 $1)", exp)
  {
    do_something_complicated_with(_match0);
    do_something_complicated_with(_match1);
  }

and do_something_complicated_with() is in the same file, and itself
uses MATCH_RTX, _match1 is liable to be clobbered, producing a nasty
and difficult-to-pin-down bug.  It's too easy to make this mistake.

>>   (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.)
>
> hmm... interesting idea; not quite sure whether I like it, seems quite
> crazy :-)  Of course we would have to hide it behind some macro
> machinery in order to keep gcc compilable, but it would solve the
> problem.

I suggested it thinking that #define AUTO static in stage1 would
suffice, but that doesn't solve the problem described above.  The
variables really must be on the stack always.

Maybe just 

foo()
{
  MATCH_RTX_VARS;
  /* other variable declarations */

  ...
  if(MATCH_RTX(...))
  {
    /* use _matchN here */
  }
}

> Of course there are also other extensions to the syntax that could be
> useful on some places (matches for modes, ability to match two
> expressions simultaneously, enabling other predicates than rtx_equal_p
> for equivalence and few others); I wanted to keep things simple for the
> beginning.

That's fair.

> I want to keep the syntax independent on whitespace. I don't like that
> there would be a fundamental semantical difference between
>
> (const (plus @base const_int@1))
>
> and
>
> (const (plus@base const_int@1))

Mm, but your syntax is unavoidably dependent on whitespace
anyway... the S-expression notation forces it.

zw