This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Language-independent functions-as-trees representation
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Jason Merrill <jason at redhat dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>,Diego Novillo <dnovillo at redhat dot com>
- Date: Mon, 22 Jul 2002 10:21:35 -0400 (EDT)
- Subject: Re: Language-independent functions-as-trees representation
>
> 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.
It happens in tons of for loops in this file, but trying to generate a
simple case (at least, in the 10 minutes i spent trying a while ago) was
not easy.
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.
>
> 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.
As long as you don't throw goto's in the body to get flow control correct,
i'm happy with any loop representation.
:)
>
> Jason
>
>