Re: [tree-ssa] Work around for an unfortunate fold-const vs.tree-optimizer interaction

[Roger Sayle <roger at eyesopen dot com>]

On Fri, 7 Nov 2003, Sebastian Pop wrote:
> On Thu, Nov 06, 2003 at 02:30:32PM -0700, Roger Sayle wrote:
> >
> > The temporary solution on the tree-ssa branch has been to duplicate the
> > constant folding code.  Given its complexity this is far less than ideal.
>
> IMO this is a side effect of the monolithic fold function.

No, this is *the* fundamental misunderstanding of the problem!

Splitting up fold into many smaller functions that handle different
aspects of constant folding would be an improvement, and help the
readability of the code to those currently unfamiliar with its
current structure but it fails to address the functionality issue.

Fold is as affective as it is because it is recursive.  After each of
the transformations it makes, it always calls "fold" on the result.
Thus each transformation in the fold code handles as step in a possibly
long sequence of changes.

This means that even if it's split up into many seemingly independent
bits, calling any one of the folders could potentially invoke any of
the others.  And if there are any in fold that are "destructive" or
introduce a SAVE_EXPR, or have any other undesirable feature, then
the entire apple barrel could be rotten.  Its very difficult "a priori"
to determine whether a tree will be constant folded into something that
contains a BITFIELD_REF.


This is the reason why the attempts to split up the functionality of
fold have failed so miserably.  Once you split out parts that you know
are "safe", they still can't call fold recursively, so they have to
call the new_fold recursively.  So the original folders can't call the
new folders without loss of functionality, and ultimately there is no
code sharing, and by its very recursieve nature both routines are
complex.


The only way to tackle the issue is to eliminate the aspects of fold
that are undesirable from all of the paths in the current code.  As
Zack has mentioned, getting rid of SAVE_EXPR would be a good start.
I'd started investigating replacing it with BIND_EXPRs, but I suspect
creating new BIND_EXPRs during tree-ssa is just as unwelcome.


Once again I have nothing against splitting-up fold into smaller, and
easier to maintain functions along the lines of simplify-rtx.c.  This
has many, many benefits.  However it wouldn't address the issue of
allowing "fold" to be used by tree-ssa without duplicating almost the
entirety of its functionality.  [Arguments that tree-ssa doesn't yet
require its entire functionality seem to indicate that the branch isn't
yet mature enough to attempt many of the optimizations performed by
fold or the RTL optimizers, and one would hope this would improve with
time :>].


Unfortunately, it appears that many of the knives that are out for
"fold", are because its "monolithic" and difficult to understand and
people are (rightly) affraid of it.  Like "reload", it isn't something
to be "hacked to pieces" lightly.  As perhaps one of the few people that
understand bits of fold's labyrinth, my biggest concern is that if the
underlying problem isn't tacked (which has absolutely nothing to do with
readability) we'll just end up duplicating code and increasing the size
of fold-const.  This creates a larger monolith making the problem that
we claim to be tackling worse.

The code duplication in builtins.c is now at 1192 lines in a 7000 line
file, i.e. 17%.  And unlike the originals none of this duplicated code
can call back into "fold".


> Anyway, sooner or later the folder has to be rewritten/reworked since
> it is one of the dinosaurs we have been left to live with...

You can only begin to imagine how frustrating it is to become a
middle-end maintainer during a stage3 bug-fix only freeze...

Roger
--
The established operating systems research community told Linus Torvalds
that with the rise of microkernels there was no future in monolithic
designs.  Its not the "monolith" but how you deal with it that counts.