Re: Language-independent functions-as-trees representation

[Jason Merrill <jason at redhat dot com>]

>>>>> "Daniel" == Daniel Berlin <dberlin@dberlin.org> writes:

> On Sun, 21 Jul 2002, Jason Merrill wrote:

>> The current simplification code explicitly unshares all the trees to avoid
>> SAVE_EXPR-like problems with shared expressions.

> Not all of them. Or at least, if it should, it's buggy.

> From a SSAPRE dump:
> In BB 111, insert save of la - lb to pretmp.4753 in statement T.4530 = la 
> - lb on line 2047
> In BB 135, insert reload of la - lb from pretmp.4753 in statement T.4676 = 
> la - lb on line 2091
> In BB 136, insert reload of la - lb from pretmp.4753 in statement T.4530 = 
> pretmp.4753 = la - lb on line 2047

> The last one occurs because, once simplified, we have:
>     for (T.4530 = la - lb; j <= T.4530; T.4530 = la - lb)
>         {

> Where the T.4530 = la - lb 's are shared.

They shouldn't be; we do a deep_copy_list so the two copies will be
unshared.

I'm feeling pretty dubious about this duplication, though.  Any duplication
of code should be done for reasons of optimization, not to try to shoehorn
the simplified code into C loop forms.  So instead of simplifying

for (; j <= la - lb;)
  { body }

that way, I think we should simplify it to

while (true)
  {
    T.4530 = la - lb;
    if (j <= T.4530)
      { body }
  }

and let loop optimization deduce an induction variable later, if it can.
I have similar issues with the insert_before_continue_end stuff.

Jason