Darf der Compiler ein lokales flüchtiges Element konstant falten?

Betrachten Sie diesen einfachen Code:

void g();

void foo()
{
    volatile bool x = false;
    if (x)
        g();
}

https://godbolt.org/z/I2kBY7

Sie können sehen, dass der potenzielle Anruf an weder optimiert gccnoch clangoptimiert wird g. Dies ist nach meinem Verständnis richtig: Die abstrakte Maschine geht davon aus, dass sich volatileVariablen jederzeit ändern können (z. B. durch Hardware-Zuordnung), sodass ein konstantes Falten der falseInitialisierung in die ifPrüfung falsch wäre.

Aber MSVC eliminiert den Aufruf von gvollständig (das Lesen und Schreiben bleibt jedoch erhalten volatile!). Ist das standardkonformes Verhalten?

^{Hintergrund: Ich verwende gelegentlich diese Art von Konstrukt, um die Debugging-Ausgabe im laufenden Betrieb ein- und ausschalten zu können: Der Compiler muss den Wert immer aus dem Speicher lesen. Wenn Sie also diese Variable / diesen Speicher während des Debuggens ändern, sollte der Steuerungsfluss entsprechend geändert werden . Der MSVC-Ausgang liest den Wert erneut, ignoriert ihn jedoch (vermutlich aufgrund ständiger Faltung und / oder Eliminierung toten Codes), was meine Absichten hier natürlich zunichte macht.}

Bearbeitungen:

• Die Eliminierung der Lese- und Schreibvorgänge volatilewird hier erläutert: Darf ein Compiler eine lokale flüchtige Variable optimieren? (Danke Nathan!). Ich denke, der Standard ist völlig klar, dass diese Lese- und Schreibvorgänge stattfinden müssen . Diese Diskussion behandelt jedoch nicht, ob es für den Compiler legal ist, die Ergebnisse dieser Lesevorgänge als selbstverständlich zu betrachten und auf dieser Grundlage zu optimieren. Ich nehme an, dass dies im Standard unter- / nicht spezifiziert ist , aber ich würde mich freuen, wenn mir jemand das Gegenteil beweisen würde.

• Ich kann natürlich xeine nicht lokale Variable erstellen, um das Problem zu umgehen. Diese Frage ist eher aus Neugier.

Ich denke, [intro.execution] (Absatznummer variiert) könnte verwendet werden, um das MSVC-Verhalten zu erklären:

Eine Instanz jedes Objekts mit automatischer Speicherdauer ist jedem Eintrag in seinem Block zugeordnet. Ein solches Objekt existiert und behält seinen zuletzt gespeicherten Wert während der Ausführung des Blocks und während der Block angehalten wird ...

Der Standard erlaubt nicht die Eliminierung eines Durchlesens eines flüchtigen Gl-Werts, aber der obige Absatz könnte so interpretiert werden, dass er die Vorhersage des Wertes ermöglicht false.

Übrigens sagt das der C-Standard (N1570 6.2.4 / 2)

Ein Objekt existiert, hat eine konstante Adresse und behält seinen zuletzt gespeicherten Wert während seiner gesamten Lebensdauer bei. ³⁴

---

34) Bei einem flüchtigen Objekt muss der letzte Speicher nicht explizit im Programm sein.

Es ist unklar, ob in einem Objekt mit automatischer Speicherdauer im C-Speicher / Objektmodell ein nicht expliziter Speicher vorhanden sein könnte.

TL; DR Der Compiler kann bei jedem flüchtigen Zugriff tun, was er will. Die Dokumentation muss Ihnen jedoch Folgendes mitteilen: "Die Semantik eines Zugriffs über einen flüchtigen Wert ist implementierungsdefiniert."

Der Standard definiert für ein Programm zulässige Sequenzen von "flüchtigen Zugriffen" und anderem "beobachtbarem Verhalten" (erreicht durch "Nebenwirkungen"), die eine Implementierung gemäß der "Als-ob" -Regel "einhalten muss.

Aber der Standard sagt (meine kühne Betonung):

Arbeitsentwurf, Standard für die Programmiersprache C ++
Dokumentnummer: N4659
Datum: 2017-03-21

§ 10.1.7.1 Die Lebenslauf-Qualifikanten

5 Die Semantik eines Zugriffs über einen flüchtigen Wert ist implementierungsdefiniert. […]

Ähnliches gilt für interaktive Geräte (meine Fettdruck-Betonung):

§ 4.6 Programmausführung

5 Eine konforme Implementierung, die ein wohlgeformtes Programm ausführt, muss dasselbe beobachtbare Verhalten erzeugen wie eine der möglichen Ausführungen der entsprechenden Instanz der abstrakten Maschine mit demselben Programm und derselben Eingabe. [...]

7 Die geringsten Anforderungen an eine konforme Implementierung sind:

(7.1) - Zugriffe durch flüchtige Werte werden streng nach den Regeln der abstrakten Maschine bewertet.
(7.2) - Bei Beendigung des Programms müssen alle in Dateien geschriebenen Daten mit einem der möglichen Ergebnisse identisch sein, die die Ausführung des Programms gemäß der abstrakten Semantik ergeben hätte.
(7.3) - Die Eingabe- und Ausgabedynamik interaktiver Geräte muss so erfolgen, dass die Aufforderung tatsächlich ausgegeben wird, bevor ein Programm auf die Eingabe wartet.Was ein interaktives Gerät ausmacht, ist implementierungsdefiniert.

Diese werden zusammen als beobachtbares Verhalten des Programms bezeichnet. [...]

(Wie auch immer welcher spezifische Code für ein Programm generiert wird , ist vom Standard nicht festgelegt.)

Obwohl der Standard besagt, dass flüchtige Zugriffe nicht aus den abstrakten Sequenzen abstrakter Maschineneffekte und daraus resultierenden beobachtbaren Verhaltensweisen herausgelöst werden können, die ein Code (möglicherweise) definiert, können Sie nicht erwarten, dass sich etwas im Objektcode oder in der realen Welt widerspiegelt Verhalten, es sei denn, Ihre Compiler-Dokumentation sagt es Ihnen was einen flüchtigen Zugriff ausmacht . Das Gleiche gilt für interaktive Geräte.

Wenn Sie in volatil vis a vis interessiert sind die abstrakten Sequenzen von abstrakten Maschine Nebenwirkungen und / oder daraus folgenden beobachtbaren Verhalten , dass einige Code (vielleicht) definiert dann so sagen . Wenn Sie jedoch daran interessiert sind, welcher entsprechende Objektcode generiert wird, müssen Sie dies im Kontext Ihres Compilers und Ihrer Kompilierung interpretieren .

Chronisch glauben Menschen fälschlicherweise, dass bei flüchtigen Zugriffen eine abstrakte Maschinenbewertung / -lesung ein implementiertes Lesen und eine abstrakte Maschinenzuweisung / -schreibung ein implementiertes Schreiben verursacht. Es gibt keine Grundlage für diese Annahme, wenn keine Implementierungsdokumentation dies sagt. Wenn / wenn die Implementierung sagt, dass sie bei einem "flüchtigen Zugriff" tatsächlich etwas tut , können die Leute zu Recht etwas erwarten - vielleicht die Erzeugung eines bestimmten Objektcodes.

Ich glaube, es ist legal, den Scheck zu überspringen.

Der Absatz, den jeder gerne zitiert

34) Bei einem flüchtigen Objekt muss der letzte Speicher nicht explizit im Programm sein

bedeutet nicht, dass eine Implementierung davon ausgehen muss, dass solche Speicher jederzeit oder für jede flüchtige Variable möglich sind. Eine Implementierung weiß, welche Speicher möglich sind. Beispielsweise ist es durchaus vernünftig anzunehmen, dass solche impliziten Schreibvorgänge nur für flüchtige Variablen auftreten, die Geräteregistern zugeordnet sind, und dass eine solche Zuordnung nur für Variablen mit externer Verknüpfung möglich ist. Oder eine Implementierung kann annehmen, dass solche Schreibvorgänge nur an wortgroßen, wortausgerichteten Speicherstellen stattfinden.

Trotzdem denke ich, dass MSVC-Verhalten ein Fehler ist. Es gibt keinen realen Grund, den Anruf zu optimieren. Eine solche Optimierung mag konform sein, ist aber unnötig böse.