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, take 2)

On Dec 5, 2007 5:11 PM, Jakub Jelinek <> wrote:
> On Wed, Dec 05, 2007 at 12:26:19PM +0100, Richard Guenther wrote:
> > 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.
> Well, if we always canonicalize to the same form, we don't risk that.

I had a careful look at the patch and it looks like we'll end up with the
same canonicalization always.  So this is fine.

> > 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.
> I've played around and combine (well, simplify_rtx) already has
> optimizations for that, unfortunately if we don't care at the tree level
> and just generate RTL, then often combiner won't be able to do something,
> because e.g. CSE intermixed the constants (seen this e.g. on the SPARC)
> and so the RTL never made it into the simplifier.

Yeah, a common problem.

> > Or you can re-factor the enabling transformations for rotates to a
> > separate routine and generate the rotates directly, not relying on
> > recursive folding.
> The transformations improve code even when not part of rotates, so I'm not
> sure that's a good idea.
> The patch below implements minimizing (which generally should create simpler
> constants on targets where some constants are too expensive), except when
> we can use mask of some integer mode (in that case either already the tree
> passes or the expander will often be able to do something better with it,
> e.g. do a widening load from memory etc.).

Ok, that makes sense.

> The testcase from this PR doesn't oscillate any longer with it, the testcase
> I gave for SPARC generates good code, etc.

This is ok if it passes bootstrap & regtest.

Thanks for your patience,

> 2007-12-05  Jakub Jelinek  <>
>         PR middle-end/34337
>         * fold-const.c (fold_binary) <case BIT_IOR_EXPR>: Don't minimize
>         number of bits set in C1 if a mode mask for some mode can be used
>         instead.
>         * gcc.c-torture/execute/20071205-1.c: New test.

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