Re: [PATCH] PR c++/17412 (ICE building Qt)

[Roger Sayle <roger at eyesopen dot com>]

On Sat, 11 Sep 2004, Steven Bosscher wrote:
> On Saturday 11 September 2004 17:40, Roger Sayle wrote:
> > Eventually, for this case, the best solution would be to add a
> > language hook for front-end specific trees in has_cleanups, so that,
> > for example, C++ could report that it's BREAK_STMT tree code doesn't
> > have clean-ups, so the middle-end could eliminate the CLEANUP_POINT_EXPR.
>
> I strongly disagree.
>
> fold-const has no business touching language specific
> trees.  When the function is lowered and the optimizers
> go to work, they can clean up whatever is there to be
> cleaned up.  Allowing fold-const to touch language
> specific trees only adds complication, and fold-const
> is already more complex than most of us would like.

It's not a matter of fold transforming language specific
trees, but its ability of the middle-end to ask reasonable
information about them.  I completely agree that the middle-end
has no business modify front-end specific trees.


The very first line of "(fold) <CLEANUP_POINT_EXPR>" is the
transformation:

    case CLEANUP_POINT_EXPR:
      if (! has_cleanups (arg0))
        return TREE_OPERAND (t, 0);

In completely language independent terms, if the tree has no
clean-ups there's no need for a CLEAN_UP_POINT_EXPR.  The relevant
code in tree.c's has_cleanups is then:


  /* This general rule works for most tree codes.  All exceptions should be
     handled above.  If this is a language-specific tree code, we can't
     trust what might be in the operand, so say we don't know
     the situation.  */
  if ((int) TREE_CODE (exp) >= (int) LAST_AND_UNUSED_TREE_CODE)
    return -1;

Which seems to me like a safe but overly pessimistic statement.
This is particularly unfortunate for languages that never require
clean-ups, as all of there tree codes are unfairly penalized.
In the case of C++'s BREAK_STMT, there's no way for the middle-end
to determine that it doesn't require any clean-ups.  The same for
trapping tree codes, commutative tree codes, non-lvalue tree codes,
etc...


So in this case, fold doesn't have to get any more complicated, but
it can do its job better if tree.c returned more accurate information.


As for fold-const.c being more complex than many of us would like,
I also suspect that the C++ front-end is more complex than many of
us would like, and more generally the task of writing optimizing
compilers is more complex than many of us would like :>  C'est la vie.
You can't make an omelette without breaking eggs.

Roger
--