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


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.

	Jakub


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