This is the mail archive of the 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] Avoid mutual recursion between BIT_{IOR,AND}_EXPR optimizations (PR middle-end/34337)

On Dec 5, 2007 12:09 PM, Jakub Jelinek <> wrote:
> On Wed, Dec 05, 2007 at 11:33:42AM +0100, Richard Guenther wrote:
> > Yes, I looked more closely and see that now.  Would my suggestion to
> > change the (arbitrary) canonicalization to maximize the number of set bits
> > in the mask fix the interactions for sure?  I think that would be a cleaner
> > patch.
> That can be a win sometimes, but a pessimization in other cases.
> We can canonicalize (X & C1) | C2 into
> (X & ((C1 & ~C2) | (C2 & C3))) | C2 where C3 can be any number we agree on.
> Using always maximization e.g. on SPARC pessimizes:
> int foo (int x) { return (x & 0xff) | 0xff000000; }
> instead of:
>         and     %o0, 0xff, %g1
>         sethi   %hi(-16777216), %o0
>         jmp     %o7+8
>          or     %g1, %o0, %o0
> after applying your patch we get:
>         sethi   %hi(-16777216), %g1
>         or      %g1, 255, %g2
>         and     %o0, %g2, %o0
>         jmp     %o7+8
>          or     %o0, %g1, %o0
> because 0xff is a cheaper constant (fits into signed 13 bit immediate),
> while 0xff0000ff is more expensive (needs 2 instructions to compute, plus
> can't be used as immediate).
> It is true that this is something the RTL simplification should have final
> say on, on the tree level I'd just say pick the new constant as mode bitmask
> if possible (i.e. (1 << N) - 1 for N 8, 16, 32, 64), otherwise minimization.

Well, IMHO on the tree level we should only do canonicalization if we do
not enable further simplifications (like with your rotate detection).  If
we apply too much magic here we risk to run into oscillations in fold again.

So from my POV always going with the maximum number of set bit on
the tree level would be ok.  We can, as a followup, try to fixup things
in combine.

Or we can refuse the canonicalization if X happens to be the result of
a shift, which is where your canonicalization will apply.

Or you can re-factor the enabling transformations for rotates to a
separate routine and generate the rotates directly, not relying on
recursive folding.


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