Re: [PATCH] Avoid mutual recursion between BIT_{IOR,AND}_EXPR optimizations (PR middle-end/34337)

[Jakub Jelinek <jakub at redhat dot com>]

On Wed, Dec 05, 2007 at 10:45:41AM +0100, Richard Guenther wrote:
> I think the problem I saw is that fold_binary is called repeatedly with
> the same trees - without any change, which is something we do not
> want to allow.  Is there extra oscillation if you fix that?

The oscillation is fixed by the patch I posted.
What was happening is:
fold_binary on BIT_IOR_EXPR ((x << 8) & 65535) | 255 called fold_binary
on BIT_AND_EXPR (x << 8) & (65535 & ~255) (which was optimized back into
(x << 8) & 65535, because 65535 is a mode mask of one of the integral
modes) and called fold_build2 (BIT_IOR_EXPR, int, (x << 8) & 65535, 255)
which means fold_binary was called again with exactly the same arguments.

> Note there is also the parallel folding of (X | C1) & C2 to (X & C2) | (C1 & C2)
> which might need similar fixing up.

Why is this related?  The new transformation I've added adds some bits
(either some least significant or most significant) to the constant second
arg of BIT_AND_EXPR.  But (X | C1) & C2 to (X & C2) | (C1 & C2) doesn't
remove bits from the constant, it changes the operator.  If we have say
((Y << C0) | C1) & C2, we transform that to ((Y << C0) & C2) | (C1 & C2),
then even if the new transformation changes this to
((Y << C0) & (C2 | C3)) | (C1 & C2) where (C2 | C3) is some mode's bitmask,
we'll hit Roger's BIT_IOR_EXPR transformation to minimize bits rather than
(X | C1) & C2 to (X & C2) | (C1 & C2) again.

	Jakub