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.


On Thu, 2005-04-21 at 07:42 +0100, Richard Sandiford wrote:
> Kazu Hirata <kazu@cs.umass.edu> writes:
> >> If your argument holds true, I'd be glad to see both the fold code
> >> and the do_jump code removed.  (At least, assuming I've understood
> >> correctly, and that this:
> >> 
> >> > 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
> >> 
> >> means that, even without the jump code, we will continue to avoid the
> >> shift on MIPS if the user writes "(X >> 2) & 1" themselves.)
> >
> > Oh, I should have been a bit more careful here.  I meant that if we
> > are setting cc0 or a MODE_CC register, combine canonicalizes a single
> > bit test into zero_extract (regardless of whether we have a & 4 or
> > (a >> 2) & 1.  If the MIPS port has no such insn, I suspect with my
> > patch, (a >> 2) & 1 would stay as is.
> 
> Ah!  That would certainly be a problem.  MIPS doesn't use MODE_CC for
> integer comparisons.  The branches compare word-mode registers against
> either another register or zero.
> 
> > If you like, I'd be happy to teach fold_binary to transform
> > (a >> 2) & 1 != 0 back to a & 4 != 0 for you
> 
> Sounds good.  FWIW, this is quite an important issue for MIPS: it led
> to a significant loss of performance in a well-known embedded benchmark
> (one that I can't name due to silly licence restrictions).
> 
> In current sources, both:
> 
>     void f1 (int x) { if (x & 4) bar (); }
> and:
>     void f2 (int x) { if ((x >> 2) & 1) bar (); }
> 
> will be implemented using an "and" with 4 followed by a branch on zero.
> We definitely want to keep this behaviour.  (I think the do_jump code
> is effectively providing the canonical form you're talking about,
> at least as far as branches go.)
You know, it might be wise to put a test for this in the testsuite if
we don't have one already.  

jeff



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