This is the mail archive of the gcc-patches@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: [PATCH][match-and-simplify]


On Tue, 3 Jun 2014, Marc Glisse wrote:

> On Tue, 3 Jun 2014, Richard Biener wrote:
> 
> > On Mon, 2 Jun 2014, Marc Glisse wrote:
> > 
> > > 
> > > >    (plus (bit_not @0) @0)
> > > >    if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
> > > >    { build_int_cst (TREE_TYPE (@0), -1); })
> > > > +(match_and_simplify
> > > > +  (plus @0 (bit_not @0))
> > > > +  if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
> > > > +  { build_int_cst (TREE_TYPE (@0), -1); })
> > > 
> > > Why not just:
> > > 
> > > (match_and_simplify
> > >   (plus @0 (bit_not @0))
> > >   { build_all_ones_cst (TREE_TYPE (@0)); })
> > > 
> > > ? Works for vector/complex, I don't know what type a bit_not_expr can have
> > > where the simplification wouldn't be true.
> > 
> > Sure.
> 
> Thanks. Sorry for not being clear enough, the same remark applies to basically
> all the bitwise patterns in the file. I could have saved the remark for the
> pre-merge RFC period. I mostly posted it now so the next batch of patterns can
> be directly written in a general way so you (Prathamesh or Richard) have fewer
> to fix later, but it can certainly wait.
> 
> /* ~~x -> x */
> (match_and_simplify
>   (bit_not (bit_not @0))
>   if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
>   @0)
> 
> We can drop the "if" line.
> 
> /* (x | CST1) & CST2 -> (x & CST2) | (CST1 & CST2) */
> (match_and_simplify
>   (bit_and (bit_ior @0 INTEGER_CST_P@1) INTEGER_CST_P@2)
>   if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
>   (bit_ior (bit_and @0 @2) (bit_and @1 @2)))
> 
> Drop the "if" line and replace INTEGER_CST_P with CONSTANT_CLASS_P.
> 
> etc.

Yeah, though we don't restrict the types that the BIT_*_EXPR operations
apply to anywhere and I wonder if this all applies to FP types
for example ... (and if we are not supposed to get FP types (or
struct types!?) here then the checking code and the tree.def documentation
should be amended).

I think the conditions we have now are literally copied from
tree-ssa-forwrpop.c (and the idea was to copy what that does 1:1).

Richard.


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