On Wed, May 7, 2014 at 3:36 PM, Prathamesh Kulkarni
<[email protected]> wrote:
> 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 ?
No, as there may be another matching pattern given that the matching
is determined by also looking at predicates which you cannot evaluate
at the time you build the decision tree.
> 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.
They would be handled after the patterns. Don't worry about them
right now (I'd add them to gimple-match-head.c for example).
> 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).
The pattern from match.pd. But as said above - don't worry about
patterns written as c-code for the moment.
> d) Should type of ifexpr be c_expr * instead of operand * in struct
> simplify since we only allow c-code in ifexpr ?
Yeah. Though the current form maybe a bit limited, so in the end
we may want to support a more "complex" prepare/conditional
step in C code, like
(match_and_simplify
(bit_and @0 INTEGER_CST@1)
if (POINTER_TYPE_P (TREE_TYPE (@0)) && tree_fits_uhwi_p (@1))
{
unsigned HOST_WIDE_INT modulus, residue;
unsigned HOST_WIDE_INT low = tree_to_uhwi (@1);
modulus = get_pointer_modulus_and_residue (@0, &residue,
integer_onep (@1));
/* This works because modulus is a power of 2. If this weren't the
case, we'd have to replace it by its greatest power-of-2
divisor: modulus & -modulus. */
if (low < modulus)
@@0 = build_int_cst (TREE_TYPE (@0), residue & low);
else
MATCH_FAIL;
}
@@0)
copied from fold-const.c case
/* If arg0 is derived from the address of an object or function, we may
be able to fold this expression using the object or function's
alignment. */
where we would want to allow arbitrary code executed at the
if-expr evaluation time which also can compute an output
(I just used double-@@ to denote outputs for example) to
use in the replacement pattern. The obvious
{ build_int_cst (TREE_TYPE (@0), residue & low); }
use in the replacement pattern doesn't work because it uses
the temporaries that are no longer in scope, and repeating the
work done in the if-expr wouldn't be good either.
The above may be not the best example motivating the extension
though. Also note the awkward use of "MATCH_FAIL" to signal
the if should make the pattern fail to match.
I suppose we should delay doing this kind of extension until we
really need it though. The RTL patterns have similar ability
though.
> 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>.
Probably good for debugging indeed. Or we can use the line-number in
the pattern description file.
> 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) ?
We should in the end only accept one form. It's ok to leave the code
as-is if you are not in a need to refactor it or apply whatever fix to
convert the uppercase tree-codes to an appropriate form at registration time.
Richard.
