On Wed, Apr 11, 2012 at 2:10 PM, Jeremy Huddleston <jerem...@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. _______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
