[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