Re: -ftree-check for review

[Nic Volanschi <nic dot volanschi at free dot fr>]

References: <200704232329.50914.nic.volanschi@free.fr>

>From: Tom Tromey <tromey at redhat dot com>
> Nic> fact, the Condate parser doesn't parse the patterns at all. It
> Nic> actually parses everything in the file except the patterns
> Nic> themselves. Why? Because writing a pattern parser is difficult
> Nic> (you'd have to extend C's grammar accordingly, and that's
> Nic> tough). Instead, I chose a simple shorthand, by rather unparsing
> Nic> the AST and comparing it with the pattern.
> 
> Ok... I hadn't read the details of the patch, so I did not realize
> this.  This doesn't strike me as a very robust way to go.

> Is it that hard to parse the kinds of statements that the checking
> pass could see?  It seems like there aren't that many kinds of
> statement in GIMPLE, and anyway we do already have a C parser lying
> around if need be.
> 

What do you mean by robust? I can see several possible meanings:

1) it's not going the usual, well-known way. That's right, but this is not 
necessarily worse. In this sense, the gcc parser is not going the 
conventional way because it doesn't use a bison grammar either, but instead 
uses a bottom-up, hard-coded parser. Personally, I see no problem with that 
(except that if it used a grammar, the tree-original dumper could have been 
generated automatically).

2) it critically relies on the dumper, so when changing the AST, the dumper 
has to be modifier accordingly. That's true, but anyways the dumper needs to 
be in sync with the AST, otherwise it's no more useful to its first function 
- debugging. Stressing the dumper might be a way to see this very quickly.

3) it doesn't warn you if you provide incorrect C patterns. That's probably 
what you meant, didn't you? That's also right, and I clearly recognize that 
this is the main disadvantage of unparsed patterns wrt parsed patterns. 
However, what will happen? These patterns simply won't match anything, but 
you will not get any nasty error. Now, what is the alternative? To extend the 
C parser to allow meta-variables in all places. (Extending the Gimple grammar 
does not implement the same feature, because (as I already described in a 
previous message) the current matcher allows to also match non-gimpelized C 
statements.) Once again, that's tough, and this is why no compiler implement 
patterns. And, you'll have to extend the C++ parser, too. And Java's, the day 
you'll compile Java to Gimple. And so on. As opposed to that, with unparsed 
patterns you have a really language-independent matcher.

Of course, if somebody extends some day any of these parsers, we can switch to 
parsed patterns for that language. We'll not loose anything in the meantime.

Nic.