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] PR opt/5263: Improve simplify_associative_operation


On Mon, 19 Jan 2004, Richard Henderson wrote:
> On Sun, Jan 18, 2004 at 06:27:15PM -0700, Roger Sayle wrote:
> > !       /* "(a op b) op (c op d)" becomes "((a op b) op c) op d)".  */
>
> Are you planning to re-balance this tree at some point?
> As-is, if we don't manage to simplify anything, this isn't a win.

Do we really need to rebalance?  Unlike trees in the constant folder,
RTL expressions are local quantities often only representing one or
two instructions.  Hence this transformation isn't serializing all
the operations in a basic block, but rather canonicalizing the RTL
representing a single instruction.

If an architecture such as the VAX (or an addressing mode on IA-32)
could perform three additions, without this canonicalization, we'd
have to provide patterns for both forms.  Similarly in combine if
we have to split "(a+b)+(c+d)" or "((a+b)+c)+d", we'd still often
end up with just two instructions with a sequential dependency.
Perhaps combine's splitting code could be made more intelligent?

We've never made an effort to balance associative/commutative trees
previously, "((a+b)+c)+d" would be left as it is, and on the plus
side, serialization of larger expressions reduces register pressure.


I appreciate balancing is an issue, I just hoped it was far less
of a concern in simplify_rtx, which is why I didn't attempt to
implement this in fold-const.c, where we really would need some
method of producing suitably skewed trees that balance register
pressure vs. parallelism (for example on a tree with 100 terms).

Roger
--


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