This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
> 
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]