This is the mail archive of the gcc@gcc.gnu.org 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] decision tree first steps


On Mon, Jun 2, 2014 at 2:12 PM, Ludovic CourtÃs <ludo@gnu.org> wrote:
> Hi,
>
> Prathamesh Kulkarni <bilbotheelffriend@gmail.com> skribis:
>
>> Example:
>> /* x & 0 -> 0 */
>> (match_and_simplify
>>   (bit_and @0 @1)
>>   if (INTEGRAL_TYPE_P (TREE_TYPE (@0)) && (@1 == integer_zero_node))
>>   { integer_zero_node; })
>>
>> /* x & -1 -> x */
>> (match_and_simplify
>>   (bit_and @0 @1)
>>   if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
>>      && (@1 == integer_minus_one_node)
>>   @0)
>
> (Apologies if this has already been discussed/decided before.)
>
> With my Scheme background, two things come to mind:
>
>   1. Wouldnât it be nicer to have a single language, rather than
>      intermingle C expressions in the middle of the s-expression
>      language?
>
>   2. Wouldnât it be useful to allow multiple clauses in a single
>      âmatchâ?
>
> Hereâs a hypothetical simplification pass one could write:
>
>   ;; Match tree node âexpâ against a series of patterns, and return
>   ;; a (possibly identical) tree node.
>   (match exp
>     ((bitwise-and first second)
>      (if (and (integral-type? (tree-type first))
>               (eq? integer-zero-node second))
>          integer-zero-node    ; simplify to zero
>          exp))                ; return âexpâ unchanged
>     ((bitwise-and first second)
>      (if (and (integral-type? (tree-type first))
>               (eq? integer-minus-one-node second))
>          first
>          exp))
>     (else                     ; no simplification pattern matched
>      exp))
>
> The language for expression rewriting (the âifâ expressions above) could
> consist of very few constructs directly translatable to C + tree.
>
> As an example, Guileâs compiler simplification passes look very much
> like this [0], built around a generic pattern matcher [1].  Pattern
> matching in MELT should also be a good source of inspiration, obviously [2].

The language is designed to be easy for the implementors ... and at
the same time match what we are used to see (thus lispy).  It's
a bit less lispy than the RTL machine descriptions which allow
RTL as their "if expressions", but I'm not sure your example is
easier to parse.

Yes, being able to combine two cases is nice - but it's also easy
to write obfuscated patterns.

(match-and-simplify
  (bit_and @0 integer_zerop@1)
  @1)
(match-and-simplify
  (bit_and @0 integer_all_onesp@1)
  @0)

is IMHO easier to parse while your version more like matches
what the code generator creates.

Richard.



> Thanks,
> Ludoâ.
>
> [0] http://git.savannah.gnu.org/cgit/guile.git/tree/module/language/tree-il/peval.scm#n1082
> [1] http://www.gnu.org/software/guile/manual/html_node/Pattern-Matching.html
> [2] http://gcc-melt.org/tutomeltimplem.html


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