Re: [tree-ssa-branch] Optimizing non-SIMPLE trees

[Daniel Berlin <dberlin at dberlin dot org>]

On Fri, 9 Aug 2002, Diego Novillo wrote:

> I ran into this problem with constant propagation and builtins.
> In string-opt-8.c we have something like this:
> 
>   const char *const s1 = "hello world";
>   const char *s2;
>   s2 = s1;
>   if (strncmp (++s2, "", 1) <= 0)
>     abort ();
> 
> The simplifier refuses to simplify the call to strncmp() because
> it contains at least one constant argument.  It does this to
> avoid tricking the code generator into not outputting a builtin
> call when all the arguments are constant.
> 
> Clearly, the simplifier could be a bit smarter in this case, but
> the point remains that we will many times refuse to simplify a
> builtin or other special trees.  The question is now, how do we
> tell the optimizers to keep their hands off these trees?

Easy.
Turn them all into tree operands of the same type of tree, then ignore 
that type of tree.

IE Introduce  NON_SIMPLE_EXPR/NON_SIMPLE_STMT nodes, with just 1 operand 
each.
All non-simplified trees become sub-trees of them.

Remove them after tree optimization (so we don't have to teach anything 
else about them).

The alternative is to add a flag to the tree_common structure, but that 
takes up space in *all* trees.

>  In this
> case, constant propagation is generating this:
> 
>   s2 = (const char * const)(char *)"hello world";
>   T.1 = strncmp ( ++(const char * const)(char *)"hello world", (const char *)(char *)"", 1);
>   if (T.1 <= 0)
>     {
>       abort (); 
>     }
> 
> Oops.  CCP didn't realize that ++s2 had side-effects.  It didn't
> have to, of course.  All the data flow information was correct,
> s2 is first used and then defined in that expression, so the
> reaching definition from the previous assignment could be
> replaced in that expression.  However, the expression wasn't in
> SIMPLE form.
> 
> An easy way out in this case would be for CCP to ask each
> expression whether it's in SIMPLE form or not.  This is a problem
> because the SIMPLE grammar is not context free w.r.t. expressions
> (a valid RHS cannot be used as a predicate inside an if() node,
> for instance).
> 
> One idea is for the simplifier to flag these trees and make them
> clobber all the symbols that they reference.  I'm not quite sure
> how this would affect other optimizers, though.

The optimizers that move things or whatnot have to track this kind of 
thing anyway. There are always things that clobber things (calls, etc).

> 
> 
> Diego.
> 
>