Re: Empty loop elimination in 4.0 ?

[Tristan Wibberley <maihem at maihem dot org>]

On Mon, 10 Jan 2005 10:14:00 -0500, Robert Dewar wrote:

> Andrew Pinski wrote:
> 
>> This:
>> int *f;
>> int i;
>> for (i=0;i<10;i++)
>>   f[i] = 0;
>> 
>> will be converted to:
>> 
>> memset (f, 0, i * sizeof(*f));
>> for (i=0;i<10;i++)
>>   ;
>> 
>> So we end up with an empty loop which then is removed by a later pass.
>> This is normal thing to do is have later passes remove junk.  The
>> pass which does this transformation has no business in acting as
>> loop DCE.
> 
> Yes, of course the warning has to be sensible enough to realize that
> this is not an empty loop from the point of view of the programmer.
> To me an empty loop is one which generates no code. Clearly the
> for loop that the programmer wrote here does generate code.

But in the C++ case it doesn't generate code. Perhaps if the parse tree
within the loop is not empty but there is no effect (ie templates with
do-nothing inline functions), then optimise. But if there is nothing then
don't. The assert case can be handled by preprocessing to a do-nothing
statement of some kind (like being an inline function that does nothing)
when NDEBUG is defined.

I'm a bit new to compilers, but could this be done by the front-end
marking a loop as being for timing if there is *actually* nothing in it.
So for (x=0;x<10;x++); is not optimised away as the front-end marks it as
timing, but for (x=0;x<10;x++) assert(blah); is optimised if NDEBUG is
defined. And for (x=0;x<10;x++) templateargument.fn(); is optimised away
if fn does nothing and is inline.

Thus no warnings necessary in normal cases, and if -std=iso99 -pedantic is
used, I suppose assert *must* be replaced by nothing, then let the
compiler just optimise it away as iso says nothing about
for(foo;bar;blah); taking time. The only thing I'm really unsure about is
what to do with loops that are known to never terminate, and loops that
can't reasonably be determined whether they terminate or not (ie, those
loops *must* *not* terminate), so this may be unsolvable in general.

-- 
Tristan Wibberley