J'utilise la déclaration de syndicat suivante dans SSE2.Spécifique 64 bits intrinsèque
typedef unsigned long uli;
typedef uli v4si __attribute__ ((vector_size(16)));
typedef union
{
v4si v;
uli data[2];
} uliv;
uliv a, b, c;
L'idée est assigner à chaque a et b deux variables unsigned long (64 bits de long), XOR eux et placer le résultat dans c.
Une affectation explicite (a.data[0] = something
) fonctionne ici mais nécessite plus de temps.
Je prévois d'utiliser des intrinsèques. Si j'utilise _mm_set_epi64 (unsigned long x, unsigned long y)
, il demande __m64
variables. Si je jette ces variables (__m64)x
et ça fonctionne bien, mais il donne un mauvais résultat.
for (k = 0; k < 10; k++)
{
simda.v = _mm_set_epi64 (_mulpre1[u1][k], _mulpre2[u2][k]);
simdb.v = _mm_set_epi64 (res1[i+k], res2[i+k]);
simdc.v = _mm_xor_si128 (simda.v, simdb.v);
}
Le code ci-dessus donne l'erreur:
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/include/emmintrin.h:578: note: expected ‘__m64’
but argument is of type ‘long unsigned int’
Pouvez-vous s'il vous plaît suggérer des solutions de rechange() intrinsèques?
1. unsigned long est de 64 bits dans ma machine. le cas (b) sera applicable à mon programme. a1, a2 sont des éléments longs non signés, mais j'obtiens l'erreur suivante (sans lancer par __m64): /usr/lib/gcc/x86_64-linux-gnu/4.4.3/include/emmintrin.h:578: note: attendu ' __m64 'mais l'argument est de type' long unsigned int ' – anup
@anup: fait partie d'une boucle, c'est-à-dire que vous avez des tableaux de valeurs dont vous avez besoin pour XOR. Si oui, il y a probablement une meilleure solution globale à cela. –
ouais, c'est une partie d'une boucle ... quelle est la meilleure solution? La situation est comme ceci, pour chaque itération je prends deux valeurs de deux tableaux différents (pas nécessairement le même index), et deux autres valeurs de deux tableaux différents, les XOR et les placez dans le second ensemble de tableaux. – anup