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

["Richard Guenther" <richard dot guenther at gmail dot com>]

On Dec 5, 2007 11:28 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> 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.

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.

Thanks,
Richard.