[Pixman] xmmintrin.h (was [PATCH 2/4] Disable MMX when incompatible clang is being used.)

Matt Turner mattst88 at gmail.com
Wed Apr 11 11:33:40 PDT 2012

On Wed, Apr 11, 2012 at 2:10 PM, Jeremy Huddleston
<jeremyhu at freedesktop.org> wrote:
> So, why not append -mno-sse when building pixman-mmx.c to ensure that doesn't happen?

Because then you can't use xmmintrin.h. Unless I'm misunderstanding
your question...

>> Try the attached patch. It's how gcc's xmmintrin.h handles it.
>> Matt
>> <p.patch>
> Sigh, that will probably do it, but I'd rather not go down a slower path on current hardware just to allow a K6-2 to be marginally faster.  Of course, if I cared about performance rather than tinderboxing, I'd be optimizing the build...

A slower path on current hardware? What?

Fast paths in pixman-mmx.c won't be used when a fast path exists for
the operation in pixman-sse2.c.

The reason for the problem you reported is that constant propagation
is necessary for the compiler to recognize that the "K" argument in
_mm_shuffle_pi16 is a constant. So, if we're not building with
optimization, we can avoid the this by defining _mm_shuffle_pi16 as a

pixman-mmx.c is mostly useless on x86. The only case where we would
really have any reason to care would be for the OLPC XO-1 with an AMD

I feel like we're going in circles and I don't understand what problem
with the previously attached patch is.

More information about the Pixman mailing list