Re: Language-independent functions-as-trees representation

[Jason Merrill <jason at redhat dot com>]

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

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

> But we don't in this case. It's a simplify_for_stmt problem, I guess.

Bizarre.  The deep-copy is unconditional.

> It does, however, demonstrate another issue with sharing.  Hard to 
> track down problems that may only occur in weird corner cases where a 
> normally unshared expression gets shared.

Yep.

>> I'm feeling pretty dubious about this duplication, though.
>> [...]
>> I have similar issues with the insert_before_continue_end stuff.

> As long as you don't throw goto's in the body to get flow control correct, 
> i'm happy with any loop representation.

Well, I basically see two options.

1) Leave for and do-while loops in their natural structure, and wait for
   the loop optimizer to decompose them completely.  Or,

2) Lower all C loops at simplification time into infinite loops, so that

  for (init; cond; incr)
    {
      body1
        continue;
      body2
    }

would turn into something like

  init
  while (true)
    {
      if (! cond)
        break;
      {
        body1
          goto cont;
        body2
      }
     cont:
      incr
    }

...where the goto could be expressed by something like an EXIT_BLOCK_EXPR;
would that be easier to deal with in optimizers?

If we stay with option 1, the way to avoid the duplication problem is to
let the condition and increment fields contain an arbitrary block of code,
not just an expression.

I suppose my question is which approach is really simpler.  In one of the
earlier threads rth referred to FOR_INIT_STMT as a useless abstraction,
suggesting that the only useful forms were the infinite loop and the
FORTRAN-like do-loop, with a strong induction variable.  On the other hand,
we currently denote the condition and continue blocks in the RTL, so it
might make sense to do so in the trees as well.

Of course, the jump-elimination pass needs something like a while loop; an
infinite loop won't do, since to get out you need break, which is a jump...

Stepping back, the chunks of a C loop are:

 Code run before the first iteration (for-init-stmt), not really part of
   the loop
Top of loop
 Code run before each iteration (anything in a for or while condition
   before the actual test)
 A conditional exit (in a for or while)
 The body
Continue point
 Code run after each iteration (the for increment expression, anything in a
   do-while condition before the actual test)
 A conditional exit (in a do-while)
 Jump to top

So a generic LOOP_STMT/LOOP_EXPR would have LOOP_EXPR_PROLOGUE (arbitrary
code), LOOP_EXPR_PRECONDITION (condexpr), LOOP_EXPR_BODY (arbitrary code),
LOOP_EXPR_EPILOGUE (arbitrary code), LOOP_EXPR_POSTCONDITION (condexpr).
This seems like a useful form; what do others think?

Jason