Hi,
I have few questions regarding genmatch:
a) When simplification fails, we continue pattern matching with the next pattern
in the order they appear in match.pd. Is that necessary ?
Could we not simply return false from gimple_match_and_simplify if
simplification fails ?
b) How do we handle manual pattern matching ? I mean
custom c-code written in match operand (Would manual matching be required?).
I believe the decision tree cannot be used for these match operands.
Either we could generate pattern matching code for these patterns
before the decision tree or after it.
c) There's a possibility of matching multiple patterns:
Contrived example:
Consider following match operands:
(minus (bit_not @0))
and the same pattern written as c-code.
In this case, which pattern do we choose to match ?
(Unfortunately, I haven't been able to think of a real example,
in which we would have multiple patterns matched).
d) Should type of ifexpr be c_expr * instead of operand * in struct
simplify since we only allow c-code in ifexpr ?
e) Should we allow an optional name for pattern in match_and_simplify ?
The name can be used as label in generated gimple_match_and_simplify
instead of L<number>.
f) Lower-case operator names: Currently we accept operator name for lowercase,
uppercase and uppercase_EXPR. This is handled with
e_operation::e_operation. If we are to settle on lower-case names,
should we remove uppercase conversion and _EXPR code in e_operation ?
This causes problems since add_operator() only adds stringified tree
codes, which are uppercase appended with _EXPR.
As a quick-fix, is it fine to convert stringified tree-codes to lower-case names
(remove _EXPR and lowercase the remaining characters) ?
