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

Jeremy Huddleston jeremyhu at freedesktop.org
Wed Apr 11 11:10:34 PDT 2012


On Apr 10, 2012, at 12:30 PM, Matt Turner <mattst88 at gmail.com> wrote:

> On Tue, Apr 10, 2012 at 1:50 AM, Jeremy Huddleston
> <jeremyhu at freedesktop.org> wrote:
>> 
>>>>>>> Newer clangs support the "K" constraint? Fixed in response to its use
>>>>>>> in pixman? :)
>>> 
>>> And to close the loop on this, the fix has landed in clang trunk and will be in 3.1:
>>> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120319/055254.html
>> 
>> 
>> And the other half of the issue seems to be a bug in pixman (at least that's what I am told):
>> 
>> """
>>> FWIW the problem happening here with inlining is that at -O0 the constant isn't being propagated through the inlining and so we have the 'K' constant error that you see.
>> 
>>  IMO, the source of this problem is that pixman isn't using clang's xmmintrin.h, which defines _mm_shuffle_pi16 for exactly this reason.  They should fix that.
>> """
> 
> Sigh. The reason we're not just plainly using xmmintrin.h is that it
> requires SSE. The MMX extension instructions we are using in
> pixman-mmx.c are available in SSE and Extended 3DNow. If you compile
> with -msse and include xmmintrin.h, you'll get lots of SSE
> instructions that aren't in 3DNow.

So, why not append -mno-sse when building pixman-mmx.c to ensure that doesn't happen?

> 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...

Acked-by: Jeremy Huddleston <jeremyhu at apple.com>





More information about the Pixman mailing list