[patch] fold-const.c: Don't transform X & C into (X >> C') & 1 in fold_binary.
Kazu Hirata
kazu@cs.umass.edu
Thu Apr 21 14:55:00 GMT 2005
Hi Richard,
> 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.)
Yes. Now your code in do_jump triggers only when the user supplies
(x >> 2) & 1. Otherwise, it's quietly sitting there.
Now, I am wondering if it's worthwhile to revert the sense of your
code. That is, if I get x & 4 != 0 in do_jump, should I convert it to
(x >> 2) & 1? Jeff speculated that on some RISC machines, loading of
constants is expensive, but if we are doing (x >> 2) & 1, we are
loading 2 anyway (although it's as small as log2 of a constant that
appears in x & C).
I'll note that on x86, do_jump converts (x >> C) & 1 back to x & C'
for any C between 1 and 31 on SImode because prefer_and_bit_test,
based on rtx_cost, thinks that the latter is cheaper.
Unless there is some compelling argument, I am inclined to removing
your code in do_jump after implementing the canonicalization in
fold_binary.
Thoughts?
Kazu Hirata
More information about the Gcc-patches
mailing list