Ist `reinterpret_cast`ing zwischen Hardware-SIMD-Vektorzeiger und dem entsprechenden Typ ein undefiniertes Verhalten?

Lesezeit: 4 Minuten

Sanddorn

Ist es legal zu reinterpret_cast ein float* zu einem __m256* und zugreifen float Objekte durch einen anderen Zeigertyp?

constexpr size_t _m256_float_step_sz = sizeof(__m256) / sizeof(float);
alignas(__m256) float stack_store[100 * _m256_float_step_sz ]{};
__m256& hwvec1 = *reinterpret_cast<__m256*>(&stack_store[0 * _m256_float_step_sz]);

using arr_t = float[_m256_float_step_sz];
arr_t& arr1 = *reinterpret_cast<float(*)[_m256_float_step_sz]>(&hwvec1);

Machen hwvec1 und arr1 darauf ankommen undefined behaviorS?

Verletzen sie strenge Aliasing-Regeln? [basic.lval]/11

Oder es gibt nur einen definierten Weg von Intrinsic:

__m256 hwvec2 = _mm256_load_ps(&stack_store[0 * _m256_float_step_sz]);
_mm256_store_ps(&stack_store[1 * _m256_float_step_sz], hwvec2);

Gottriegel

Warum verstößt es Ihrer Meinung nach nicht gegen die strenge Aliasing-Regel? Meiner Meinung nach verstößt Ihr erster Code dagegen. Ich würde dafür Intrinsics verwenden, genau wie Sie vorschlagen.

– geza

31. August 2018 um 10:14 Uhr
@geza Danke. Ich bin mir nur unsicher, weil auf die unterstrichene Darstellung nie als ein anderer Typ als zugegriffen werden kann float

– Sanddorn

31. August 2018 um 10:21 Uhr
Willst du es nicht als verwenden __m256 auch? Wenn nicht, was ist dann der Sinn? 🙂

– geza

31. August 2018 um 10:22 Uhr
@geza Also Ihrer Meinung nach, Zugriff auf Floats, die sich darin befinden __m256 Objekt und innerhalb __m256 Lebenszeit gegen strenge Aliasing-Regeln verstoßen?

– Sanddorn

31. August 2018 um 13:12 Uhr
Ja, ich würde es nicht tun. Es gibt eine sicherlich nicht verletzende Lösung, ich würde stattdessen Load/Store Intrinsics verwenden. Der einzige Grund, reinterpret_cast zu wählen, wenn es aus irgendeinem Grund schneller ist. Aber aktuelle Compiler sind ziemlich gut darin, solche Sachen zu optimieren.

– geza

31. August 2018 um 13:41 Uhr

Seltsamerweise ist icc (im Gegensatz zu gcc und clang) im Allgemeinen ausgefeilt genug, um das zu erkennen, wenn ein Zeiger konvertiert wird T* zu U*und verwendet wird, um auf den Speicher zuzugreifen, bevor das nächste Mal auf andere Weise darauf zugegriffen wird, kann eine solche Operation tatsächlich den Wert von beeinflussen T in Frage (d. h. es kann in Fällen mit Typ-Wortspielen umgehen die nicht wirklich Aliasing beinhalten) deuten meine Tests darauf hin, dass solche Fälle nicht behandelt werden, wenn es sich um Typen handelt __m256* und uint32_t*auch wenn die uint32_t* wird von demselben Zeigerobjekt abgeleitet, das für den Zugriff auf verwendet wird __m256.

– Superkatze

31. August 2018 um 21:17 Uhr
Du denkst, das ist nah genug an einem Betrüger von: stackoverflow.com/questions/24787268/… ? Meine Stimme ist bindend, also zögere ich, den Abzug zu betätigen.

– Mystisch

31. August 2018 um 21:45 Uhr
@Mystcial: hrm, ja unsere Antworten könnten jeweils fast beide Fragen beantworten, obwohl die Fragen etwas anders sind (der andere scheint das anzunehmen _mm_storeu_pd wird die gleiche Aliasing-Semantik wie eine Dereferenzierung haben, aber es ist eine intrinsische, also könnte es alles tun.) Ich mag meine Antwort besser, denn anstatt zu sagen, dass es (scheinbar) UB gibt, aber es funktioniert, sage ich, dass Compiler which Intrinsik unterstützen tun Definieren Sie das Verhalten in diesem Fall. Das ist mein einziges Zögern beim Duphammering. Vielleicht sollte ich meine dort neu posten?

– Peter Cordes

31. August 2018 um 22:03 Uhr
Oder schließen Sie das als Dup davon? Aber deine Antwort ist auch gut.

– Peter Cordes

31. August 2018 um 22:03 Uhr
@Mystcial Ich mag deine Antwort auch, besonders die nachfolgenden allgemeinen Richtlinien.

– Sanddorn

1. September 2018 um 5:03 Uhr

__m256 wird von der Implementierung bereitgestellt. Es ist eine Erweiterung.

– n. 1.8e9-wo-ist-meine-Aktie m.

31. August 2018 um 9:51 Uhr
@MSalters wird durch die Implementierung definiert, __m256 Es ist nicht nur erlaubt, sondern sogar erforderlich, einen reservierten Namen zu verwenden.

– Erorika

31. August 2018 um 10:26 Uhr
@geza: Der Standard verlangt nicht, dass Implementierungen für einen bestimmten Zweck oder irgendeinen Zweck nützlich sind. Die Frage, was eine Qualitätsimplementierung tun muss, um für jeden Zweck geeignet zu sein, ist weitgehend orthogonal zu der Frage, was eine Implementierung tun muss, um dem C-Standard zu entsprechen.

– Superkatze

31. August 2018 um 17:02 Uhr
@geza: Wenn eine Aktion undefiniertes Verhalten aufruft, bedeutet dies, dass sich ein Compiler möglicherweise auf eine Weise verhält, die ihn für einige Zwecke ungeeignet macht und dennoch konform ist. Einige Compiler-Autoren scheinen zu glauben, dass Programmierer kein Recht haben, von einem Compiler etwas anderes zu erwarten, als dass er “konform” ist (z. B. dass er für die Zwecke geeignet ist, denen ihre Programme dienen sollen) und dass jeder Code, der darauf angewiesen ist auf Dinge, die darüber hinaus “kaputt” sind. Eine solche Ansicht ist meiner Meinung nach absurd, scheint aber die aktuelle Compiler-Philosophie zu steuern.

– Superkatze

31. August 2018 um 17:09 Uhr
@MSalters: Ich denke, die von Ihnen gepostete Antwort ist richtig, aber nicht nützlich. Wir wollen die Semantik von wissen __m256* auf Implementierungen, die es überhaupt erst definieren, und die darauf abzielen, mit Intels Implementierung / Dokumentation kompatibel zu sein. Der ISO-C++-Standard sagt darüber natürlich nichts aus. Ich habe eine Antwort gepostet, die es aus diesem Blickwinkel anspricht.

– Peter Cordes

31. August 2018 um 21:28 Uhr

9901100cookie-checkIst `reinterpret_cast`ing zwischen Hardware-SIMD-Vektorzeiger und dem entsprechenden Typ ein undefiniertes Verhalten?

#c++ #Eigenheiten #Sprachjurist #undefiniertes Verhalten #x86