[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
macro.
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
Geode.
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