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 Wed, 2005-04-20 at 17:25 -0400, Kazu Hirata wrote:
> Hi,
> 
> Attached is a patch to teach fold_binary not to transform
> 
>   X & C
> 
> into
> 
>   (X >> C) & 1.
Where C is a power of 2, of course.


> 
> Note that fold_single_bit_test, a subroutine of fold_binary,
> transforms
> 
>   int a = ...;
>   if (a & 4)
> 
> into
> 
>   a.0_2 = (unsigned int) a_1;
>   D.1236_3 = a.0_2 >> 2;
>   D.1237_4 = (int) D.1236_3;
>   D.1238_5 = D.1237_4 & 1;
>   if (D.1238_5 != 0) goto <L0>; else goto <L1>;
> 
> which is pretty long.  The patch disables this transformation for
> fold.  In the above example, we would instead have
> 
>   D.1235_2 = a_1 & 4;
>   if (D.1235_2 != 0) goto <L0>; else goto <L1>;
Seems reasonable to me -- I've never done any research to understand
why we have generated the first form as opposed to the second form
for trees.


> 
> 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.

jeff




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