Re: [PATCH] Constant fold -A - B as -B - A

[Roger Sayle <roger at www dot eyesopen dot com>]

Hi Neil,
> > Not only is it also safe for integer constants, but also for
> > other forms of expressions that are cheaply negated.  The obvious
> > case is where B is a negation, i.e. -C, would transform -A - -C
> > into C - A, but this is already handled by constant folding.
>
> This worries me about fold-const.c: how much is redundant?

fold contains the transformations, that X - -Y is the same as
X + Y, and that -P + Q can be transformed into Q - P, hence can
convert -A - -B into B - A already.  Both of these transformations
have their own utilty, but their combination also happens to
handle a subset of the new "-A - B" rules.  All three rules are
required for coverage, but there exist cases may match more than
one rule.


> There does not appear to be a overall plan to folding, it's just
> ad-hoc.
>
> Whether this is a problem or not I have no idea, but it sure makes
> it unclear what's really going on.

If it helps ease some of your concern, there is a plan.

The eventual goal is to have constant-folding optimizations
"duplicated" in two places.  The first in "fold" to perform
simplifications at the tree-level, available to SSA and friends.
The second is in "simplify_rtx" to perform simplifications on
RTL available to the RTL optimizers.

As described in http://gcc.gnu.org/projects/beginner.html, this
goal is currently hampered by there being three sets of RTL
simplification routines: simplify_rtx in simplify-rtx.c (the one
true routine),  fold_rtx in cse.c and combine_simplify_rtx in
combine.c.  Work is in progress to merge these.

For example, Geoff Keating's excellent work recently on canonicalizing
negation, http://gcc.gnu.org/ml/gcc-patches/2002-12/msg00161.html,
was added to combine_simplify_rtx [where its related transformations
currrently live] rather than be shared in simplify_rtx.

Once there are just "fold" and "simplify-rtx", it'll be possible
to check that most of the transformations done in one, are also
performed by the other (where applicable).

The final goal is to determine the constant folding optimizations
performed by specific back-ends, to pull the generic ones into
the common code.  For example, Kazu Hirata has been doing an
extremely impressive job with optimizations for the H8300, but
many of his transformations could also benefit many other targets.


Personally, I think one of GCC's great strengths is the encyclopaedic
depth of its constant folding optimizations.  Its one of the parts
of the compiler that benefits from years of patches from hundreds of
contributors.


Roger
--
[If you want to desert-going beast of burden, design it by commitee :>]