This is the mail archive of the 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: [tree-ssa] PATCH to &&/|| gimplification

On Fri, 23 May 2003 12:57:11 -0700, Richard Henderson <> wrote:

> On Tue, May 20, 2003 at 04:17:41PM -0400, Jason Merrill wrote:
>>   int main()
>>   {
>>     int i = 0;
>>     int j;
>>     while (1)
>>       {
>>         if (i>2)
>>           break;
>>         j = i;
>>         ++i;
>>       }
>>     return j;
>>   }
>> The RTL loop optimizer isn't clever enough to know that we will always
>> execute the loop at least once, so j will always be initialized before use.
> This is because the loop rotation code in expand_end_loop doesn't fire.
> Which is because we don't emit a NOTE_INSN_LOOP_END_TOP_COND note.  See
> the commentary there and in the gcc-patches message that created

Yes, our current loop optimizer has many limitations.  I would expect a
rewritten loop optimizer that actually uses the cfg to handle this fine.
There's no theoretical reason for the explicit loop condition to be

>> I think this bug needs to be fixed in the loop optimizer.
> Not possible, IMO, for the reasons listed indirectly above.
> The gimplifier either needs to rotate the loop itself, i.e. generate
> 	if (i > 2)
> 	  do {
> 	    // ...
> 	  } while (i <= 2);

This is easily done in simplify_c_loop, but I worry about duplication of
code when the condition is complex (i.e. an inlined function).  Generating

goto cond;
while (1)
    // ...
     if (i>2)

is also pretty straightforward, but doesn't silence the warning.

> or leave simple conditionals in the WHILE_COND, or... I dunno.

There is no WHILE_COND.  All loops in GIMPLE are infinite loops.  There may
be another loop tree code later to handle canonicalized loops, but there
hasn't been any work on that yet.

On Fri, 23 May 2003 13:01:55 -0700, Zack Weinberg <> wrote:

> Note that I'd like to see the tree->RTL converter get a lot simpler in
> the future, which would imply that more work should be done in the
> GIMPLE representation.  Loop rotation seems to me like something that
> belongs done on trees.  In fact, I could argue that all the loop
> optimizations ought to happen then, too.



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