Es ist ein bekanntes Problem , dass das Mischen von VEX-kodierten Anweisungen und Nicht-VEX-Anweisungen eine Strafe bedeutet und der Programmierer sich dessen bewusst sein muss.
Es gibt einige Fragen und Antworten wie das . Die Lösungen hängen von der Art und Weise ab, wie Sie programmieren (normalerweise sollten Sie zeroupper nach den Übergängen verwenden. Aber meine Frage bezieht sich auf das EVEX-kodierte Schema. So weit es keine Eigenheiten wie _mm512_zeroupper() gibt VEX-kodierte und EVEX-kodierte Instruktionen zusammen, aber EVEX ist 4-Byte und VEX ist 3-Byte und auch die Vektorlänge ist 512-Bit bzw. 256-Bit.
Weil AVX-512 nicht verfügbar ist (zumindest für mich). Ich wollte fragen, ob es etwas zu beachten gibt, wenn wir sie mischen wollen.
Es gibt keine Nachteile für das Mischen von VEX 128/256 oder EVEX 128/256/512 mit aktuellen CPUs, und es gibt keinen Grund, mit zukünftigen CPUs zu rechnen.
Alle VEX- und EVEX-codierten Befehle sind so definiert, dass sie die hohen Bytes des Zielvektorregisters auf Null setzen, unabhängig von der maximalen Vektorbreite, die die CPU unterstützt. Das macht sie zukunftssicher für zukünftige, breitere Vektoren, ohne hässliche Sachen wie vzeroupper zu benötigen.
Ein VEX-codiertes vpxor xmm0,xmm0,xmm0 ist bereits der effizienteste Weg, um ein ZMM-Register zu zerlegen , wobei 2 Bytes vs. vpxord zmm0,zmm0,zmm0 gespeichert werden und mindestens genauso schnell ausgeführt werden. MSVC macht das schon eine Weile, und clam 6.0 (trunk) macht es auch, nachdem ich die verpasste Optimierung gemeldet habe . (
Peter Cordes
07.09.2017, 00:56