gcc-Optimierungen u. Warteschleifen?

[nobody0]

Also bisher dachte ich, dass der gcc gemäß ANSI-C optimiert, also beispielsweise diese Warteschleife wegoptimiert, wenn alle Optimierungen aktiviert sind (-O5):

long int i=0;
while (++i<1234567890);

Aber die Ausführungszeit von

int
main (void)
{
long int i=0;
while (++i<1234567890);
return (0);
}

zeigt, dass dies nicht so ist.
Wie bekommt man denn solche Warteschleifen ohne volatile-Variablen vom gcc korrekt wegoptimiert?

[wraith]

Also bisher dachte ich, dass der gcc gemäß ANSI-C optimiert,

Wo wird im Standard beschrieben, wie optimiert werden soll?

also beispielsweise diese Warteschleife wegoptimiert, wenn alle Optimierungen aktiviert sind (-O5):

-O5 gibt es nicht, alles -Ox mit x > 3 wird zu -O3.

Wie bekommt man denn solche Warteschleifen ohne volatile-Variablen vom gcc korrekt wegoptimiert?

Versuch mal -funroll-loops (+ sonstige Optimierungen).

[nobody0]

Also im Standard steht zu volatile objects, dass die nicht optimiert werden dürfen, außer bei der Evaluiertung von Ausdrücken (6.7.3).

Nach 5.1.2.3.8 kann alles vom Compiler als volatile behandelt werden (u. einige ältere machen das immer noch, so das nicht portabler Code damit gemacht wird), aber gewöhnliche Compiler machen das nicht; d. h. die vewenden volatile Objekte anders als die anderen.
Zudem ist nach 5.1.2.3.9 alles an Optimierungen zulässig, was im Einklang mit der abstrakten Semantik ist,also beispielseise

while (++i<1234567890); -> ; // wegoptimiert

Es gibt da keinen Grund diese Warteschleife nicht wegzuoptimieren, weil die keinen semantischen Seiteneffekt hat, da die Schleifenvariable nicht volatile ist.

Also mit -funroll-loops funktioniert das auch mit dem gcc, aber ich hatte erwartet, dass der die falsche Warteschleife auch so korrekt wegoptimiert; mit -O3 wird also nicht allzuviel optimiert.

Edit: Also mit -funroll-loops wird es um den Faktor 10 schneller; d. h. es wird nicht ganz wegoptimiert. Das zeigt sich beim Varrieren der oberen Grenze von i.

[Ringding]

Aus der GCC Doku:

* Deleting "empty" loops.

Historically, GCC has not deleted "empty" loops under the
assumption that the most likely reason you would put one in a
program is to have a delay, so deleting them will not make real
programs run any faster.

However, the rationale here is that optimization of a nonempty loop
cannot produce an empty one, which holds for C but is not always
the case for C++.

Moreover, with `-funroll-loops' small "empty" loops are already
removed, so the current behavior is both sub-optimal and
inconsistent and will change in the future.

[nobody0]

Aha, danke