[Pixman] [cairo] help building cairo on windows

[Siarhei Siamashka]

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

As for the MSVC warnings, they look rather bogus and useless. MSVC
just spams the log with false alarms for the small inline functions
and possibly catches itself at wrong code generation (which should
not normally happen in the first place). Maybe the warnings can be
suppressed as suggested at
    https://bugzilla.mozilla.org/show_bug.cgi?id=682139 ?

-- 
Best regards,
Siarhei Siamashka