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] fold-const.c: Don't transform X & C into (X >> C') & 1in fold_binary.


Hi Jeff,

> > AFAICT, it does not matter whether we do this transformation or not as
> > far as conditional branches are concerned.  Combine canonicalizes a
> > single bit test into zero_extract regardless of whether we have
> > 
> >   a & 4
> > 
> > or
> > 
> >   (a >> 2) & 1
> > 
> > Also the transformation does not matter for a store flag operation
> > because do_store_flag calls fold_single_bit_test to transform
> > 
> >   var = (a & 4) != 0;
> > 
> > into
> > 
> >   var = (a >> 2) & 1;
> > 
> > So all in all, the "SHIFT and AND" form seems to do nothing but take
> > up a lot of statements during tree optimizations.
> The only ways I can see the shift-and style working better would be
> if it exposes CSE opportunities and/or reducing the size of the 
> constants used in the instructions (think about risc targets that
> require multiple instructions to generate arbitrary constants.
> 
> Even so, these are, IMHO, clearly issues that need to be resolved
> later in compilation -- for the tree optimizers we should choose the
> form which most clearly represents what the code is trying to 
> accomplish.  So you're not going to get any objections from me.

Yes, at the tree level, we want to have forms that are easier to
analyze.  Not necessarily one-to-one correspondence with assembly
language.

Well, can I consider my patch approved?  You, Richard Henderson,
Richard Sandiford, Roger Sayle, and I all like the patch.  No
objection from anybody.

Kazu Hirata


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