[Pixman] [cairo] help building cairo on windows

[Siarhei Siamashka]

On Thu, 13 Sep 2012 14:25:32 -0700
Matt Turner <mattst88 at gmail.com> wrote:

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

This is not surprising for rare and almost extinct hardware such as
x86 processors without SSE2. And it is not MSVC specific at all. For
example, pixman-0.26.0 had MMX bug slipped in because of the same
"exotic hardware needed to reproduce the problem" reason not so
long ago:
    http://cgit.freedesktop.org/pixman/commit/?h=0.26&id=bfbfa2cc8fbc43

The only difference is that linux users are more familiar with autotools
and do run 'make check' sometimes. Windows users are more likely to
start worrying only after spotting graphics artefacts, crashes or
other obvious symptoms.

There is one more thing to consider: some people just fix trivial bugs
and apply patches without bothering to report back.

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

First of all, both gcc and MSVC are suffering from EMMS related
problems. The gcc bug 47759 is still unresolved, and I doubt that
anyone is going to invest efforts into fixing it, considering that
MMX is going away in the long run. And it has already proved to break
pixman in the wild (admittedly only reproducible with a strange
optimization flags combination "-march=athlon-xp -msse2"):
    https://bugs.gentoo.org/show_bug.cgi?id=347947:
I'm pretty sure there is a chance to encounter this problem again in
the future. One only might need to be a bit creative with CFLAGS
selection when compiling pixman.

Non-x86 systems don't need any EMMS at all, that's a noop for them.
Yes, the code gets worse because of the extra #ifdef clutter added, but
I don't see many options here. It's either
1) workaround it
2) stop using MMX on x86 hardware
3) do nothing, blame GCC and MSVC :)

We are effectively at 3) now. But the very existence of this discussion
thread proves that this unresolved problem is going to be recurring
and eat our time, regardless of who is at fault.

-- 
Best regards,
Siarhei Siamashka