Code: Alles auswählen
static_assert(+2 / 2 == 1);
static_assert(+1 / 2 == 0);
static_assert( 0 / 2 == 0);
static_assert(-1 / 2 == 0); // !!!
static_assert(-2 / 2 == -1);
static_assert(-3 / 2 == -1);
static_assert(-4 / 2 == -2);
static_assert(+2 >> 1 == 1);
static_assert(+1 >> 1 == 0);
static_assert( 0 >> 1 == 0);
static_assert(-1 >> 1 == -1); // !!!
static_assert(-2 >> 1 == -1);
static_assert(-3 >> 1 == -2);
static_assert(-4 >> 1 == -2);Früher war es implementation defined, seit C++20 ist es wohldefiniert.
Meinem Verständnis nach waren die Typen von Pointern auf LLVM IR Ebene schon seit langem nicht (nie?) für Optimierungen nutzbar. Und Typechecking ist etwas, was eh das Frontend schon besser macht. Was für den Optimizer wirklich interessant ist, ist zu wissen ob und wo welche Pointer aliasen oder nicht. Und das wird nicht über Typen sondern über andere Metadata gehandled. Von daher seh ich eigentlich nicht, was hier das Problem sein sollte. Wenn überhaupt, sollte die Performance davon profitieren, dass nutzlose Komplexität losgeworden wird. Der Artikel erklärt es auch:Lord Delvin hat geschrieben: ↑09.12.2023, 18:08 Kann mir auch nicht vorstellen, dass sich das gut auf die Performance auswirkt. Weder Compilezeit noch Laufzeit, wenn man voll optimieren will.
LLVM IR pointers can be cast back and forth between pointers with different pointee types. The pointee type does not necessarily represent the actual underlying type in memory. In other words, the pointee type carries no real semantics.
[…], the community realized that pointee types were more of a hindrance for LLVM development and that the extra type checking with some frontends wasn’t worth it.
Edit 2: Interessantes Zeug drin.https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286#c18 hat geschrieben:What is your position based upon? Mine is based upon having been in the room when we decided what the C rules probably were, what the C++ rules could be, […]
TBAA accounts for about 7-25% of alias disambiguations in the real world for C and C++ (combined). This is according to both papers published by Intel about ICC, papers published by MS about VC, papers published by IBM about XLC, and testing of Google's codebase with and without -fno-strict-aliasing (with the caveat that we know our codebase is not entirely strict aliasing safe)
Das invoked im ersten Durchlauf UB. var ist nicht transparently replaceable mit einem float.Krishty hat geschrieben: ↑12.12.2023, 20:56 Und, weniger natürlich, aus Placement new. Beispiel (ich glaube, das war der GCC-Bug):
int var;
for(int i = 0; i < 123; i++) {
if(i & 1)
new (&var) int(42);
else
new (&var) float(42.f);
someFunction(var);
}
Bei jedem geraden Schleifendurchlauf ist var ein float und bei jedem ungeraden ein int. In someFunction() hat TBAA keine Chance, Aliasing aufzulösen. Bist du optimistisch, hast du einen Compiler-Bug. Bist du pessimistisch, hast du keine Optimierung mehr.
Aber erst ab C++20 IIRC? In C++17 und davor dürfte das gültig sein, weil es dieses Konzept damals noch nicht gab.dot hat geschrieben: ↑12.12.2023, 22:30Das invoked im ersten Durchlauf UB. var ist nicht transparently replaceable mit einem float.
Soweit ich das sehe war das seit C++98 UB. C++20 hat lediglich die Anforderungen bezüglich const etwas gelockert. Hier die entsprechende Passage aus C++11 (steht genau gleich auch in meinem C++03 PDF hier): https://timsong-cpp.github.io/cppwp/n33 ... c.life#7.2Krishty hat geschrieben: ↑12.12.2023, 23:29Aber erst ab C++20 IIRC? In C++17 und davor dürfte das gültig sein, weil es dieses Konzept damals noch nicht gab.dot hat geschrieben: ↑12.12.2023, 22:30Das invoked im ersten Durchlauf UB. var ist nicht transparently replaceable mit einem float.
Oh, ich lese es jetzt anders. Ich muss den Satz etwas zusammenkürzen weil der so lang ist:dot hat geschrieben: ↑12.12.2023, 23:41Soweit ich das sehe war das seit C++98 UB. C++20 hat lediglich die Anforderungen bezüglich const etwas gelockert. Hier die entsprechende Passage aus C++11 (steht genau gleich auch in meinem C++03 PDF hier): https://timsong-cpp.github.io/cppwp/n33 ... c.life#7.2
Das gilt für:If, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, a new object is created at the storage location which the original object occupied
Aus dem Rest deines Paragraphen streiche ich mal den Clutter, der hier nicht zutrifft:The lifetime of an object o of type T ends when: […] the storage which the object occupies is released, or is reused by an object that is not nested within o
Der Absatz bezieht sich ausschließlich auf Manipulation des neuen Objekts durch den alten Namen, also:a pointer that pointed to the original object, a reference that referred to the original object, orthe name of the original object will automatically refer to the new object and, once the lifetime of the new object has started,can be used to manipulate the new object, if the original object is transparently replaceable(see below)
In deinem Beispiel benutzt du den alten Namen (`var`) um eine Funktion aufzurufen, no?Krishty hat geschrieben: ↑13.12.2023, 09:12 Der Absatz bezieht sich ausschließlich auf Manipulation des neuen Objekts durch den alten Namen, also:
i = 42; // Illegal! Nicht transparently replaceable! Dies ist nun ein float!
Das Ergebnis des Placement New kann hingegen problemlos genutzt werden, um das Objekt zu manipulieren:
float * f = new (&i) float{ 42.f }; // lifetime i end; f ist nun Alias auf i
*f = 43.f; // OK
Bitte lies Kommentare 17 und 18 im GCC-Ticket!
Korrekt, das Ergebnis des Placement-New kann problemlos genutzt werden. Das ursprüngliche Beispiel nutzt aber nicht das Ergebnis des Placement-New, sondern den alten Namen des Objektes. Und der kann nicht mehr genutzt werden, weil das Placement-New die Lifetime des entsprechenden Objektes beendet hat und das alte Objekt nicht transparently replaceable durch das Neue ist (bzw. pre C++20: nicht den selben Typ hat).
Also bei mir wäre da schon offense intendet ;) Der ganze Web-Quatsch ist doch das schlimmste und ineffizienteste, was die Informatik in den letzten 50 Jahren Zustande gebracht hat. Der erste Firefox ist jetzt fast 20 Jahre alt, und der hat damals wie heute ein bisschen Menüs, ein bisschen Text und ein bisschen Bilder dargestellt. Natürlich gibts zig Kleinigkeiten die man irgendwie als verbessert argumentieren kann, aber vergleich das mal mit dem was sich z.B. in 3D Grafik getan hat.Chromanoid hat geschrieben: ↑23.12.2023, 20:35mit irgendwelchen WebViews von Webentwicklern (no offense intended)
