Re: [tree-ssa] where to fix this?

[Roger Sayle <roger at eyesopen dot com>]

On Thu, 8 Jan 2004 law@redhat.com wrote:
> Roger Sayle writes:
>  >My vote for the reorganization of "fold", and the passing of additional
>  >parameters, is to do something like the current implementation of
>  >"fold_initializer" in fold-const.c.  The interface is simple to the
>  >outside world, sets up the required behaviour of "fold" and then
>  >invokes fold itself.
> Seems reasonable to me.  Though I would tend to worry about getting a
> ton of functions, particularly since I want to be able to call into
> the folder without generating a tree expression all the time.  ie,
>
> ada_fold_gimple_relational
> f90_fold_gimple_unary
> f95_fold_nongimple_binary
> c_fold_expr
>
> But I guess if we put them into the lang hooks or something like that
> we'd just do something like
>
> fold_gimple_relational (opcode, type, op0, op1)
>
> Where fold_gimple_relational is an appropriate #define which looks in
> the lang hooks.


I also much prefer the simplify_rtx style of constant folding interface,
passing in opcode, type and operands.  I'd envisaged that underneath
the current "fold", "fold_initializer", "fold_builtin", "simplify_tree"
public interfaces that take a single tree, which we need support in
perpituity, (or atleast during a transitionary period), they'd actually be
implemented via the "shape" of function used above; "fold_unary",
"fold_binary", "fold_ternary".

The existing (and reused by fold_initializer) interface then becomes a
shallow wrapper routine:

tree fold(tree orig)
{
  tree t;

  switch (TREE_CODE (orig))
  {
  case PLUS_EXPR:
  case MULT_EXPR:
  case MINUS_EXPR:
    t = fold_binary (TREE_CODE (orig), TREE_TYPE (orig),
		     TREE_OPERAND (orig, 0), TREE_OPERAND (orig, 1));
    break;

  case NEGATE_EXPR:
  case BIT_NOT_EXPR:
    t = fold_unary (TREE_CODE (orig), TREE_TYPE (orig),
		    TREE_OPERAND (orig, 0));
    break;

  ...

  default:
    t = NULL_TREE;
  }
  return t ? t : orig;
}


As can be seen there are two complementary but not quite independent
clean-ups pending for fold-const.c, one to reuse and share as much of
the logic as possible (providing wrapper interfaces) [my previous
message] and the other that changes the shape of these interfaces
(providing wrapper functions for backwards compatibility) [above].

The problem with the tree-ssa branch is that it started attacking the
second issue of providing alternate interfaces before tackling the first
of reusing code.  The result is lots of functions that duplicate
functionality in different forms, instead of shallow wrappers.


Ultimately, all the main logic code will be shared in the large functions
fold_binary, fold_unary, etc...  Users of the constant folding APIs then
can use their choice of tree vs. operands interfaces.  Certainly we'll
no longer need to create/allocate a tree node just to determine whether
an expression can potentially be folded into something else, e.g. is
a constant.


I think we're both on the same page, the discussion above is primarily
for the benefit of the rest of the list.  As to the topic of language
and front-end specific constant folding using langhooks, I'm certain
you've given the issue far more thought than I have.


The additional comment I will make, to suggestions made on the list, is
that it is better to fold expressions during construction than it is to
build a tree first and fold afterwards.  Consider "!!!!!!!!!!!!!!!!!x"
and similar trees that are manageable provided you fold as you build.
fold isn't currently recursive, making the assumption that the operands
of a tree-node have already been folded/canonicalized at the point their
parent is folded.  The conclusion is that a "strict" front-end shouldn't
rely on fold preserving the TREE_CODE and/or TREE_TYPE for the purposes
of parsing and semantic analysis.  As has been pointed out, GCC can fold
more expressions to constants than are considered integer constants by
the C/C++ language standards.  The parser should record such information
as part of the parse state, with the folded tree being a "opaque"
representation (handle) of the AST built so far.


Roger
--