On Wed, Jan 14, 2015 at 3:26 PM, Marc Glisse <marc.gli...@inria.fr> wrote: > On Wed, 14 Jan 2015, Richard Biener wrote: > >> On Wed, Jan 14, 2015 at 1:45 PM, Marc Glisse <marc.gli...@inria.fr> wrote: >>> >>> On Tue, 13 Jan 2015, Rasmus Villemoes wrote: >>> >>>> diff --git gcc/match.pd gcc/match.pd >>>> index 81c4ee6..04a0bc4 100644 >>>> --- gcc/match.pd >>>> +++ gcc/match.pd >>>> @@ -262,6 +262,16 @@ along with GCC; see the file COPYING3. If not see >>>> (abs tree_expr_nonnegative_p@0) >>>> @0) >>>> >>>> +/* x + (x & 1) -> (x + 1) & ~1 */ >>>> +(simplify >>>> + (plus @0 (bit_and @0 integer_onep@1)) >>>> + (bit_and (plus @0 @1) (bit_not @1))) >>>> + >>>> +/* x | ~(x | y) -> x | ~y */ >>>> +(simplify >>>> + (bit_ior @0 (bit_not (bit_ior @0 @1))) >>>> + (bit_ior @0 (bit_not @1))) >>> >>> >>> >>> You may want to consider using has_single_use (see other patterns). >> >> >> Just to clarify, you mean on the (x | y) sub-expression? > > > I meant on (x & 1) for the first pattern and on ~(x | y) for the second one. > That is, cases where the transformation could actually increase the number > of statements (we don't have a convenient interface to check if (x+1) or ~y > are already available). > > (x | y) could sometimes be cheaper than y if it is already computed and it > shortens the lifetime of y, but we are way too early in the pipeline to make > an informed decision about that, so it seems better to canonicalize.
Yeah. Note that I've not yet settled myself on how to attack the "single-use issue" generally. For example I'd like to do code generation for a specific simplification variant for value-numbering which can check the availability of expressions - here explicit has_single_use calls wil be prohibitive. It should be the responsibility of the caller to apply restrictions like this (but for the tree-ssa-forwprop.c case I've not yet come up with a reasonable way to tame things down...) Richard. > Now that I think about it, some platforms probably have an instruction > ornot, so my reasons above could be wrong... > -- > Marc Glisse
