Re: [lmi] MinGW-w64 anomaly?

[Greg Chicares]

On 2016-12-21 14:23, Vadim Zeitlin wrote:
> On Wed, 21 Dec 2016 02:09:09 +0000 Greg Chicares <address@hidden> wrote:
[...SSE...]
> GC> I'd like to measure the effect on our 32-bit msw production release.
> GC> How might I do that?
> 
>  I think the first step would be for me to finish my changes making things
> work with SSE (or, rather, with any standard-compliant C++11
> implementation) by getting rid of all x87-specific code "properly".

How about conditionalizing it instead of "getting rid of" it?

> GC> Still, AFAICT this is the relevant change:
[...]
> GC> and I'm not quite sure how replacing a cover function that simply
> GC> delegated to C99 rint() with direct calls to std::rint() could
> GC> make a difference
> 
>  No, sorry, this is not the right change. The change in the commit
> 54d250300e367b33af5719c40087e5536640fa1f which really broke it was to
> remove
> 
>       template<typename RealType>
>       inline RealType perform_rint(RealType r)
>       {
>           __asm__ ("frndint" : "=t" (r) : "0" (r));
>           return r;
>       }
> 
> and replace the calls to it with std::rint(). The old version worked
> because it used x87 instruction which was governed by the x87 rounding
> mode. The new version doesn't work because it uses the SSE instruction
> (some _mm_cvtsd_xxx I think), but the rounding mode is not set for SSE
> (this would require modifying MXCSR register instead of the x87 control
> word).

Okay, so if I revert that, conditional on LMI_X86, that will undo
any damage? Or should I use something like
  #if defined __SSE__ || (defined _M_IX86_FP && _M_IX86_FP)
instead? Or does C++11 offer a standard way of doing this?

> GC> >  Otherwise you'd either need to revert the std::rint() change or we'll 
> have
> GC> > to live with completely broken 64 bit (and MSVC, which also uses SSE)
> GC> > versions which is IMHO not ideal.
> GC> 
> GC> I'd rather not live with that much breakage. I wonder whether there's
> GC> some temporary fix that would be less drastic than reverting the rint()
> GC> patch mentioned above. Wait--is the whole lmi build broken for those
> GC> toolchains, or only these two unit tests?
> 
>  I don't see any halfway fix, unfortunately. Either we use SSE and then we
> can't use any x87-specific code, or we don't.

Can we make everything work with msvc and with 64-bit gcc by
conditionalizing any x87-specific code?

>  And while the build, per se, is not broken, lmi is broken in the sense
> that the computations it performs presumably give incorrect results.

I'm not sure whether you're saying the 32-bit production system is
"broken" in this sense; I think that would be too strong a statement,
like saying that all programs were "broken" before SSE.

> Unless
> the rounding mode is never changed while doing them? But this is probably
> not the case, otherwise why would we have all the code dealing with it in
> the first place...

We check that the control word always remains 0x037f:
 03 round to nearest, extended precision
 7f mask all hardware exceptions
Of course, a library routine may push a different control word
on entry and pop the original on exit. We take steps to protect
ourselves against evil msw dlls that stomp on the control word,
and we have good reason to believe those steps are effective.

>  Anyhow, for me the important question is whether you'd like me to produce
> a reasonable patch (right now I just have a dirty hack) allowing the
> rounding tests to pass when not using x87 by replacing x87-specific code
> with the standard functions (based on/inspired by my ~10 year old IEC 559
> patch) or if it's not worth doing it, either because it won't get done at
> all (which would be sad) or because you prefer to do it yourself?

If you're asking me to decide now to give up extended precision
unconditionally and forever, then I'd probably have to decline.

If the x87 advantages that were nullified by SSE can be made
conditional without introducing too much ugliness, then I'd be
inclined to accept that. Is that what the decade-old patch did?
If so, maybe I should take a quick look at it now.

I would not prefer to do this work myself.