Re: Don't trust your optimizer :-)
Am 23.11.2010 14:36, schrieb Bart van Ingen Schenau:
On Nov 19, 9:16 pm, Daniel Kr?gler<daniel.krueg...@googlemail.com>
wrote:
It would be very helpful, if you could just define the frame code of
main and the infinite loop. There is no need to reveal details, it would
be sufficient to declare some functions that are called during entry and
in the context of the loop or loops and to argue that this is part of an
existing software product.
First, the software is written in C for a freestanding implementation
using an ARM processor. The software has a built-in cooperative
multitasking OS.
The loop in question is also NOT located in main or a function called
from there.
The code in main goes roughly like this:
[..]
Thanks very much Bart. I have forwarded this example to the core language group as a real world example to consider in the discussions.
I can understand that it would be nice to be able to merge those two
loops.
The problem is just that the proposed text also affects loops that can
easily be proven to not terminate.
I think most objections could be met if the license to assume a loop
terminates is only granted if the controlling expression is not a
constexpr (or empty in case of a for loop).
The clause could be written as:
6 An iteration statement that performs no input/output operations,
does not access volatile objects, and performs no synchronization or
atomic operations in its body, controlling expression, or (in the case
of a for statement) its expression-3, and whose controlling expression
is not a constexpr, may be assumed by the implementation to terminate.
154)
This means that, if the termination can be determined at compile time,
then the compiler may not make any assumptions. It has to execute the
loop as the abstract machine would do it.
If the controlling expression can not be evaluated at compile time,
the compiler may assume the loop will eventually terminate and perform
optimisations based on that assumption.
To my knowledge, if an infinite loop is intended, then the controlling
expression will invariably be a constant expression.
I agree that this looks like a very reasonable criterion. I have been told that C currently discusses some infinite-loop patterns, but AFAIK they have not found yet good general rules - the simple cases are covered, though, e.g.
while (c) { /../ }
do { /../ } while (c);
for (/../; ; /../) { /../ }
where c is a constant expression != 0.
Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]