Comments on: Fast SSE Select Operation

By: Revisiting Fast SSE Select at mark++

Revisiting Fast SSE Select at mark++ — Tue, 08 Apr 2008 22:51:08 +0000

[...] started thinking about this SSE select operation again, probably round about the time I learned of AMD’s SSEPlus and its [...]

By: Mark

Mark — Thu, 05 Apr 2007 19:49:25 +0000

Wendy helped me to understand why my code is *not* susceptible to the problem you describe, Kent. The answer does not have much of anything to do with “const”, despite what I said previously.

The reason my version is safe is quite simply that my _mm_sel_ps_xor function does not ever modify any of its parameters.

Sure, the const qualification helps prevent a mistake, but as long as I am careful not to modify my reference parameters, I’m golden.

Insert head-slapping “duh” here.

For illustrative purposes, here’s a version that is vulnerable to the problem you describe:


_mm_sel_ps_xor_BAD_BAD_BAD( __m128& a, __m128& b, const __m128& mask)
{
    b = _mm_xor_ps( b, a );
    return _mm_xor_ps( a, _mm_and_ps( mask, b ) );
}

By: Mark

Mark — Thu, 05 Apr 2007 05:32:34 +0000

I think my version is OK with const references, right? The compiler must not modify either of the source memory locations.

By: Kent

Kent — Thu, 05 Apr 2007 00:51:55 +0000

Hey bud,

I love this optimization too, but it’s not perfect. It has a tiny flaw if you pass two references to the same memory location. If that happens the xor’s will wipe out all bits, no matter the mask. Ideally, if you want to merge the same memory location, you want to get the source back unmodified. You can only use the xor approach if you can guarantee that &a != &b.

If you can’t, you need to use the andnot approach.