Minor C/C++ parser clean-up request

[Roger Sayle <roger at eyesopen dot com>]

As a middle-end person, I've been investigating what it would take to
address some of the tree-inlining performance issues currently being
experienced on mainline.

As pointed out to me, when I submitted my patches for middle-end dead
code elimination and eliminating calls to pure/const functions, many
of these transformations for reducing unused or unreachable RTL in the
expanders, should really be applied much earlier in the "front-ends".
We really need to minimize the size of the tree representation as this
is where inlining takes place, which prior to DCE provides inaccurate
insn count estimates to the inlining heuristics.

Jeff Law has also mentioned that it would be better for tree-ssa
if the front-ends optimized trees prior to the SSA passes, which
would avoid the latter building large CFGs of unreachable basic
blocks only to be cleaned up eventually.

>From my analysis, I propose that the correct way to tackle this is
via a new function "fold_stmt", that is called after build_stmt but
before add_stmt in an analogous way to how "fold" is (almost) always
called after build for expressions.  And like fold doesn't need
to recurse (i.e. it can assume its arguments have been folded), the
same strategy for a fold_stmt would avoid the significant overhead
of traversing nested language constructs in later passes.


Unfortunately, the major blockage in such a strategy is the poor
separation between the C-family parsers and the statement building
code.  The parsers call add_stmt with partial and/or incomplete
statement trees, then later modify the tree structure via private
pointers after its been passed off to the middle-end.  This makes
assumptions about the TREE_CODEs and contents of earlier statements
and prevents the middle-end from performing many transformations
or optimizations.

As an example, see the uses of RECHAIN_STMTS and last_tree in the
parser, including the use in c_finish_then.

This poor interface between front-ends and middle-end obfuscates
the point at which the middle-end can know definitively that a
tree is fully constructed during the building process.

If the parsers were tidied up such that statement trees were must
be fully constructed before they are passed to "add_stmt", this
routine could call "fold_stmt" itself, and allow it to do a much
better task of maintaining DECL_NUM_STMTS.  Indeed, if it knew
nothing was going to change behind its back, it could use a better
parameterized model of function size, estimating the number of
instructions in the current function from the types of the
folded statements being added.


Might I propose a polite request that we try to move towards
consistently building trees in a write-only bottom-up fashion.

Many thanks for your patience,

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833