Re: [tree-ssa] fold-const trick for gzip

[Roger Sayle <roger at eyesopen dot com>]

On Wed, 10 Dec 2003, Richard Henderson wrote:
>
> On Tue, Dec 09, 2003 at 07:50:02PM -0700, Roger Sayle wrote:
> > Personally, I'd much prefer this optimization to be implemented in
> > fold-const.c as its two component "atomic" transformations.
>
> This should be done in ifcvt.c, and probably nowhere else.
>

I strongly agree that constant folding transformations of COND_EXPRs
should *also* appear in ifcvt.c, but pragmatically they really need to
be done in (1) in "fold" of fold-const.c, (2) in "noce_process_if_block"
in ifcvt.c, and (3) in "simplify_ternary_operation" in simplify-rtx.c.
Each of these covers a slightly different set of cases from the other
two, and in an optimizing compiler, we really need all three.


If-conversion alone is unsuitable, for example, for "a ? b : c" if any
of a, b or c requires more than a single RTL instruction or two to
evaluate, for example.  Constant folding COND_EXPRs at the tree-level
makes these simplifications visible to tree-ssa, and reduces the number
of insns and basic blocks that the RTL optimizers have to deal with,
and allows the more powerful CSE to operate on insns that would
otherwise require GCSE, etc...


As for the first "atomic" transformation that just needs to appear in
(1) "fold" in fold-const.c and (2) "simplify_relational_operation" in
simplify-rtx.c.


The good news is that in addition to unifying cse.c's fold_rtx and
combine.c's combine_simplify_rtx into simplify-rtx.c's simplify_rtx,
there are also efforts underway to ensure that the same set of
transformations that are available to the RTL optimizers are also
available to tree-ssa, and vice versa.  "x ^ x", "x & x" and "x | x"
aren't yet folded at the tree-level for example.


But let me know if you feel the duplication is more than a necessary
evil resulting from having more than one internal representation?

Roger
--