Thursday, May 7. 2009
Do you need 128 1s?
When programming with SSE there are some cases where you need a double-quad vector filled with all 1s. E.g. for a simple bitwise not:
_mm_andnot_ps(x, 1);
(This does a (~x & ~0) which of course is equal to ~x, the bitwise not we were looking for.) The bitwise not is necessary to implement some of the missing comparisons. SSE2 only has integer comparisons for ==, < and >. To implement !=, <= and >= you need a bitwise not.
So now that I motivated your need for a double quad with all 1s, where do you get it from? Well, easy, you say. Put a constant there. OK, it's 128 bits big, but what does that matter. And you're right, except if the constant is not in the L1 cache. Because then the load of the constant from L2 cache will introduce some unnecessary latency. So yes, it's a solution but not the nicest one.
Here's a better one. Remember that a comparison in SSE gives you a full double-quad. And if the comparison of the entries in the vector says they were all equal (for cmpeq, that is) you get a double-quad filled with 1s. Great... let's do it:
static inline __m128 _my_setallone() {
__m128 r;
return _mm_cmpeq_ps(r, r);
}
Works. Nice... except gcc warns about an uninitialized variable r being used. Looking at the generated code we see it added another xor instruction to initialize the register to 0. Ugh.
__m128 r;
return _mm_cmpeq_ps(r, r);
}
I can do better than two instructions. I want one! So inline assembly it is:
static inline __m128 _my_setallone() {
__m128 r;
__asm__ ("cmpeqps %0,%0":"=x"(r)::);
return r;
}
You'd expect that to work? I sure did. And sometimes it did. Sometimes it didn't. Huh? Guessing... put a __volatile__ there: Less failures. But not cured. So remove the __volatile__ again and objdump -d the binary while doing instruction steps in gdb in a split view in Konsole (nice feature there!). And what do I see. After cmpeqps was called on a register that register is all 0s! Why oh why? How can the same thing not be equal. So I look at the value of the register before the call: 4 NaNs (at least when interpreted as 4 floats). I slap my head, remember that NaNs are never equal to anything, and look for the integer comparison instruction.
__m128 r;
__asm__ ("cmpeqps %0,%0":"=x"(r)::);
return r;
}
The result:
static inline __m128i _my_setallone() {
__m128i r;
__asm__ ("pcmpeqb %0,%0":"=x"(r)::);
return r;
}
Perfect. Now it works. I am able to do a bitwise not in two instructions (gcc is able to keep the xmm register around for another pandn, so this is also as good as it can get) and I don't have to worry about the cache at all.
__m128i r;
__asm__ ("pcmpeqb %0,%0":"=x"(r)::);
return r;
}
Lesson learned: don't mess with floating point instructions when trying to do bit magic.
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
On AMD "pcmpeqb/d" uses an extra instruction and blocks the fadd pipe for 1 cycle, so a load from cached memory will be faster. Address generation on AMD is free.
Intel Core has 3 ports that can handle "pcmpeqb/d", so it is less likely that this will cause a delay, although one could probably write (likely nonsense) code that executes faster with a load. Use a recently used scratch register to avoid a register read stall.
But I would assume the pcmpeqb/d to still be faster than a L2 load, no? L1 load should be faster than pcmpeqb/d on both Intel and AMD AFAIU.
Regarding the register read stall: The way the code above is written gcc decides what register it uses. Though perhaps gcc gets fooled by r not being in the read list of the asm call?
I think, you'll get the fastest code by declaring a global register variable, which would also be architecture oblivious. If you are lucky, GCC will put it in e.g. xmm15 once and call it a day.
Can you post what you want the function to do? I love doing this kind of puzzle.
static inline VectorType cmpneq(VectorType a, VectorType b)
{
return _mm_andnot_si128(cmpeq(a, b), _my_setallone_si128());
}
static inline VectorType cmpnlt(VectorType a, VectorType b)
{
return _mm_andnot_si128(cmplt(a, b), _my_setallone_si128());
}
static inline VectorType cmple (VectorType a, VectorType b)
{
return _mm_andnot_si128(cmpgt(a, b), _my_setallone_si128());
}
And in the end used to implement operator==, !=, >, >=, <, and <= for a SSE::Vector<int> class.
Declaring a constant __m128 poses an interesting problem, though. So far the only working code I know of is to either put an array of 4 ints aligned to a 16 byte boundary and call _mm_load everytime you want to use it, or use a union like
static const union {
unsigned int m[4];
__m128 v;
} ALLONE = { { 0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFFFF } };
Both is ugly, but both work alright.
static inline VectorType cmple (VectorType a, VectorType b)
{
return _mm_andnot_si128(cmpgt(b, a);
}
In the worst case this generates an extra movdqa (if the input needs to be preserved).
I haven't thought about it too much, but you can probably eliminate every cmpneq, simply by replacing following pandn with pand and vice versa.
You should be able to declare a global register variable like this:
register __m128i ones asm("xmm15")=_mm_set1_epi32(0xffffffff);
But it's probably better to make it a static member.
static inline VectorType cmple (VectorType a, VectorType b)
{
return _mm_cmpgt(b,a);
}
Calendar
|
November '09 | |||||
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | ||||||
Quicksearch
Categories
Syndicate This Blog
Blog Administration
Powered by
