[Pixman] [cairo] help building cairo on windows

[Matt Turner]

On Thu, Sep 13, 2012 at 12:15 PM, Siarhei Siamashka
<siarhei.siamashka at gmail.com> wrote:
> On Thu, 13 Sep 2012 09:08:59 +0200
> Andrea Canciani <ranma42 at gmail.com> wrote:
>
>> On Thu, Sep 13, 2012 at 2:08 AM, Siarhei Siamashka
>> <siarhei.siamashka at gmail.com> wrote:
>> >
>> > I'm not sure if I can provide much help with MSVC. The _mm_empty()
>> > intrinsic is also not totally problem free even when using gcc:
>> >     http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47759
>> >
>> > But some kind of workaround is still needed. Can you try to
>> > confirm which pixman fast paths are triggering this problem?
>>
>> It looks like the compiler warning match the issue:
>> fast_composite_scaled_bilinear_mmx_8888_8_8888_pad_OVER
>> fast_composite_scaled_bilinear_mmx_8888_8_8888_none_OVER
>>
>> >
>> > If the problem is related to incorrect EMMS instruction reordering,
>> > then maybe moving EMMS into a non-inlinable function and calling it
>> > instead of _mm_empty() can help? Just as an experiment for getting
>> > a bit better understanding about what is going on.
>>
>> I confirm that it is likely to be an optimization bug (disabling the
>> optimizations fixes it).
>> The attached patch is another possible workaround to the issue.
>> It causes a lot of warnings about missing EMMS, because the compiler
>> does not find any EMMS instruction after the MMX instructions), but
>> the whole testsuite succeeds.
>> Marking the function as noinline (without disabling the optimizations
>> on it) does not fix the issue.
>>
>> What would be the best way to work around this issue both in gcc and
>> in msvc? Would it be ok to create a "pixman_mm_empty()" function (to
>> be used everywhere instead of mm_empty) and disable the optimizations
>> on it?
>
> Maybe we can add a new function pointer to pixman_implementation_t
> specifically for EMMS instruction, which can be initialized in
> _pixman_implementation_create_mmx() for x86 systems?

I will NAK this with all the power I have.

> It would be best if we could ensure that this function is really called
> and never inlined, preferably in a portable way. I guess the compiler
> can't easily prove that the function pointer is never overwritten
> elsewhere even with link time optimizations, so it will emit a function
> call.

It turns out that Windows/MSVC build problems are reported, but no one
actually uses the MMX code on Windows. See commit 4fc586c3d. That bug
was introduced in a075a870fd7 in 2009 and apparently no one noticed
until I happened to come across it by inspection 3 years later.

I'm okay with non-invasive fixes like f71e3dba, but I won't let the
MMX code get worse because of MSVC crap. It's actually important to
some platforms, and Windows/MSVC isn't one of them.