Re: [patch] fold-const.c: Don't transform X & C into (X >> C') & 1in fold_binary.

[Kazu Hirata <kazu at cs dot umass dot edu>]

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