Was ist die Verfügbarkeit von 'Vektor lang lang'?

Ich teste auf einem alten PowerMac G5, der eine Power4 Maschine ist. Der Build versagt:Was ist die Verfügbarkeit von 'Vektor lang lang'?

$ make 
... 
g++ -DNDEBUG -g2 -O3 -mcpu=power4 -maltivec -c ppc-simd.cpp 
ppc-crypto.h:36: error: use of 'long long' in AltiVec types is invalid 
make: *** [ppc-simd.o] Error 1

Der Fehler ist durch:

typedef __vector unsigned long long uint64x2_p8;

Ich habe Probleme bestimmen, wann ich sollte die typedef zur Verfügung stellen. Mit -mcpu=power4 -maltivec meldet die Maschine 64-Bit-Verfügbarkeit:

$ gcc -mcpu=power4 -maltivec -dM -E - </dev/null | sort | egrep -i -E 'power|ARCH' 
#define _ARCH_PPC 1 
#define _ARCH_PPC64 1 
#define __POWERPC__ 1

Das OpenPOWER | 6.1. Vector Data Types Handbuch eine gute Informationen über Vektordatentypen hat, aber nicht diskutieren, wenn die vector long long zur Verfügung stehen.

Was ist die Verfügbarkeit von __vector unsigned long long? Wann kann ich den Typedef verwenden?

Quelle

2017-12-12 jww

Obwohl der G5 64-Bit * -Architektur * hatte, hatte AltiVec damals keine Unterstützung für 64-Bit-Vektorelemente, also auch keine 64-Bit-Ints und keine Double-Precision-Floats. –

Danke Paul. Wir partitionieren Code um Power4 (Altivec), Power7 (nicht ausgerichtete Lasten/Speicher) und Power8 (In-Core-Krypto). Ich denke, meine Frage ist, müssen wir Power5 anstelle von Power4 für den 64-Bit-Typ verwenden? – jww

Ich bin mir nicht sicher, welche Generation von POWER 64-Bit-Elementtypen für SIMD eingeführt hat - Sie müssten etwas nachforschen, um das herauszufinden. Natürlich können Sie Ihren Code auf einem G5 nicht testen, wenn Sie 64-Bit-Elemente verwenden müssen. –

TL: DR: Es sieht so aus, als ob POWER7 die Mindestanforderung für 64-Bit-Elementgröße mit AltiVec ist. Dies ist Teil von VSX (Vector Scalar Extension), die Wikipedia erstmals in POWER7 veröffentlicht bestätigt.

Es ist sehr wahrscheinlich, dass gcc weiß, was er tut, und ermöglicht 64-Bit-Element-Größe Vektor-Spezifika mit der niedrigsten notwendigen -mcpu= Anforderung.

#include <altivec.h> 

auto vec32(void) {  // compiles with your options: Power4 
    return vec_splats((int) 1); 
} 

// gcc error: use of 'long long' in AltiVec types is invalid without -mvsx 
vector long long vec64(void) { 
    return vec_splats((long long) 1); 
}

(Mit auto anstelle von vector long long, die 2. Funktion kompiliert in zwei 64-Bit-Integer-Register zurück.)

Hinzufügen -mvsx kann die 2. Funktion der Kompilierung. Die Verwendung von -mcpu=power7 funktioniert auch, aber power6 nicht.

source + asm on Godbolt (PowerPC64 gcc6.3)

# with auto without VSX: 
vec64():  # -O3 -mcpu=power4 -maltivec -mregnames 
    li %r4,1 
    li %r3,1 
    blr

vec64(): # -O3 -mcpu=power7 -maltivec -mregnames 
.LCF2: 
0: addis 2,12,[email protected] 
    addi 2,2,[email protected] 
    addis %r9,%r2,[email protected]@ha 
    addi %r9,%r9,[email protected]@l  # PC-relative addressing for static constant, I think. 
    lxvd2x %vs34,0,%r9   # vector load? 
    xxpermdi %vs34,%vs34,%vs34,2 
    blr 


.LC0: # in .rodata 
    .quad 1 
    .quad 1

Und BTW, vec_splats (Splat Skalar) mit einem konstanten compiliert auf einen einzigen Befehl. Aber mit einer Laufzeitvariablen (z. B. einer Funktion arg) kompiliert es zu einem ganzzahligen Speicher/Vektor load/vector-splat (wie der intrinsische vec_splat). Anscheinend gibt es keinen einzigen Befehl für int-> vec.

Der vec_splat_s32 und verwandt intrinsics nur einen kleinen (5 Bit) anzunehmen, so dass sie kompiliert nur dann, wenn der Compiler den entsprechenden Spritzabschreckverfahren SOFORT-Befehl verwenden.

Diese Intel SSE to PowerPC AltiVec migration sieht meist gut aus, aber das ist falsch (es behauptet, dass vec_splats splasst ein vorzeichenbehaftetes Byte).

Quelle

2017-12-26 02:26:36

Was ist die Verfügbarkeit von 'Vektor lang lang'?

Antwort

Verwandte Themen