This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Missing simplifications in simplify_plus_minus
- From: Roger Sayle <roger at eyesopen dot com>
- To: Andreas Krebbel <krebbel1 at de dot ibm dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Paolo Bonzini <bonzini at gnu dot org>
- Date: Fri, 10 Feb 2006 07:14:36 -0700 (MST)
- Subject: Re: [PATCH] Missing simplifications in simplify_plus_minus
On Fri, 10 Feb 2006, Andreas Krebbel wrote:
> 2006-02-10 Andreas Krebbel <krebbel1@de.ibm.com>
>
> * simplify-rtx.c (simplify_plus_minus): Remove variable
> 'canonicalized'.
Hmm. Clearly there's a missed optimization issue with Paolo's changes
but I think that completely removing canonicalized is not the correct
solution.
My concern is memory usage. simplify_plus_minus should return a
new RTL expression if it performs a simplification or reorders operands
in order to produce canonical RTL. If no transformation/simplification
can be made it should return NULL_RTX. This NULL_RTX is important
for the higher-level RTL transformations, that will themselves allocate
a new pattern if some part of an operand changed.
Getting these semantics right is tricky. Originally, the test was
over-conservative so a force flag was added to always transform a
plus/minus. This still failed to handle canonicalization so Paolo
added code to allow (plus (const_int 1) (reg)) to be simplified.
But this change weakened the test so (minus (reg A) (reg A)), no
longer fires. Your proposed patch swings us the other way, such
that simplify_plus_minus only return a NULL_RTX on error. i.e.
simplification of (plus (reg X) (reg Y)) will allocate and return
the same expression "(plus (reg X) (reg Y))". Though functional,
I suspect we'll see a jump in memory usage.
What I'd like to see is a patch that keeps track of whether the
returned RTL would be different from the input RTL, preferrably
without reallocating it. As a bonus it would be great if terms
(subexpressions) that are invariant are also reused.
It's early, and I haven't given the mechanics much thought, so I
can't immediately see a solution/implementation, but the above
comments should explain what the underlying problem is.
Roger
--