SSE3/SSSE3 + AES/RDRAND/RDSEED unter Sun Studio

Question

Ich arbeite unter Sun Studio 12.3 auf SunOS 5.11 (Solaris 11.3). Ich optimiere ein Skript, das negative Tests enthält und ungewöhnliche Kombinationen von CPU-Features enthält. Wir tun dies, um zu verstehen, ob und wie wir versagen; und um sicherzustellen, dass es no unexpected surprises gibt.

Ich versuche einen Weg zu finden, um den nativen Befehlssatz plus AES, RDRAND und RSEED zu aktivieren. Der native Befehlssatz ist mit freundlicher Genehmigung von Xeon 5100, was effektiv SSE3/SSSE3 plus einige zusätzliche Anweisungen ist.

Kompilieren alle Quelldateien mit /opt/solarisstudio12.3/bin/CC -DNDEBUG -g3 -xO2 -template=no%extdef -native -m64 -KPIC -xarch=aes -D__AES__=1 Ergebnisse in:

$ ./cryptest.exe 
ld.so.1: cryptest.exe: fatal: cryptest.exe: hardware capability (CA_SUNW_HW_1) unsupported: 0x1000000 [ SSE4.2 ] 
Killed 

Dies ist eine Art zu erwarten, da Sun Studio nimmt eine Progression von Features und Verfügbarkeit. Wenn ich das Makefile zum Erstellen von cpu.cpp (für Feature-Tests verwendet), rijndael.cpp (AES-Implementierung) und test.cpp (führt den Test) mit -xarch=aes erstellen, stürzt das Programm noch ab, weil SSE4 in test.cpp kriecht.

Ich habe versucht, -xarch=aes -D__AES__=1 -xarch=no%sse4_1 -xarch=no%sse4_2 zu verwenden, um unerwünschte Befehlssätze zu entfernen, aber es konnte nicht wie erwartet kompiliert werden. no%sse4_1 kommt einfach von -template=no%extdef, weil das no% Präfix scheint, um die Dinge auszuschalten.

Wie verwende ich SSE3/SSSE3 mit dem Zusatz von AES/RDRAND/RDSEED unter Sun Studio? Ist es überhaupt möglich?

Das Muster, das wir bisher verwendet haben, ist die Kombination von Kompilierzeitunterstützung mit Laufzeitunterstützung. So wird AES Code wie folgt aussehen:

#if (__AES__ >= 1) || (SUNPRO_CC >= 0x512) 
# define HAVE_AES 1 
#endif 

#if defined(HAVE_AES) 
if (HasAES()) 
{ 
    // Optimized implementation 
    ... 
    return; 
} 
#endif 
{ 
    // Fall into C/C++ implementation 
    ... 
} 

Für Compiler wie Clang und GCC, wir einfach -march=native -maes -mrdrnd -mrdseed. Ich war froh zu akzeptieren, dass keine Kreuzigung stattgefunden hat.

Dann cam über zwei Nachrichten auf Oracles Message Boards zeigt RDRAND ist unter Sun Studio 12.3 und 12.4 (here for 12.3 und here for 12.4) gebrochen. Also muss ich sicherstellen, dass RDRAND aktiviert ist, um sicherzustellen, dass es getestet wird, und das erfordert -xarch=aes.

---

Basierend auf _mm_aeskeygenassist_si128 intrinsic requires at least -xarch=aes ist dies möglicherweise nicht möglich. Diese Frage ist effektiv, um sicherzustellen, dass wir alles tun, um eine problemlose Erfahrung zu gewährleisten.

---

$ isainfo -v 
64-bit amd64 applications 
     ssse3 ahf cx16 sse3 sse2 sse fxsr mmx cmov amd_sysc cx8 tsc fpu 
32-bit i386 applications 
     ssse3 ahf cx16 sse3 sse2 sse fxsr mmx cmov sep cx8 tsc fpu 

Answer 1

Dort habe ich eine AES + SSSE3 binäre für Sie erstellt.

 
$ cat tmp.c 
#include 
#include 
#include 
int main(int argc, char* argv[]) 
{ 
    // SSE2 
    int64_t x[2]; 
    __m128i y = _mm_loadu_si128((__m128i*)x); 

    // AES 
    __m128i z = _mm_aeskeygenassist_si128(y,0); 

    return 0; 
} 

$ cat tmp2.c 
#include 
#include 
void foo(void) 
{  
     __m128i x; 
     x  = _mm_hadd_epi16 (x, x); 
} 

$ cc tmp.c tmp2.c -xarch=aes 
tmp.c: 
tmp2.c: 

$ file a.out 
a.out:   ELF 32-bit LSB executable 80386 Version 1 [AES SSSE3 SSE2 SSE], dynamically linked, not stripped 

Die Hardware-Capabilities-Bits durch den Compiler abhängig von der tatsächlichen Anwesenheit von insructions in den endgültigen ausführbaren assinged werden.

Also tmp.o hat AES Bit zugewiesen. Und tmp2.o hat bis zu SSSE3 Bits assinsed.

Wenn sie miteinander verbunden sind, produzieren sie [AES SSSE3] binär. Denn HWCAP Bits sind OR Ed zusammen.