This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [GSoC] Few questions regarding genmatch

On Wed, May 7, 2014 at 3:36 PM, Prathamesh Kulkarni
<> 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

   (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);

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

> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]