Re: [lmi] MinGW-w64 anomaly?

[Vadim Zeitlin]

On Wed, 21 Dec 2016 16:37:09 +0000 Greg Chicares <address@hidden> wrote:

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

 In the long term, I don't think there is any benefit in keeping both
versions. The standard doesn't cover all the functionality of fenv_lmi.hpp
but fenv_precision() is not really used anywhere (only in the tests) and
I think a better way to implement fenv_validate() would be by performing
some computation(s) with known good answer(s) and comparing that their
results match the expected ones.

 But for now, yes, we could make the choice between the 2 implementations a
compile-time option for validation/testing purposes.

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

 There is no standard way of checking for this to the best of my knowledge
(it would be really surprising if there were, seeing how this is entirely
architecture-specific) and so you would indeed need to test for __SSE__ for
gcc and, if you're so inclined, for _M_IX86_FP > 0 for MSVC (where this is
more complicated because this one is only defined if _M_IX86 is defined).

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

 Well, yes, but why? If we replace x87-specific code with the standard
functions we could (and would) still compile it using x87 instructions in
32 bits with gcc if/as you wish to continue doing it, so why keep it?

GC> >  And while the build, per se, is not broken, lmi is broken in the sense
GC> > that the computations it performs presumably give incorrect results.
GC> 
GC> I'm not sure whether you're saying the 32-bit production system is
GC> "broken" in this sense; I think that would be too strong a statement,
GC> like saying that all programs were "broken" before SSE.

 This was because I thought we did use different rounding styles in lmi
code (which would have made it broken). But I was wrong...

GC> > Unless the rounding mode is never changed while doing them? But this
GC> > is probably not the case, otherwise why would we have all the code
GC> > dealing with it in the first place...
GC> 
GC> We check that the control word always remains 0x037f:
GC>  03 round to nearest, extended precision
GC>  7f mask all hardware exceptions

 ... because apparently we don't ever do this. But now I really wonder why
do we have all this code in the first place?

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

 No, sorry, this is not at all the question. I ask you to only give up
*explicit* use of x87 instructions. This doesn't preclude us from compiling
the code to use them -- but it also allows compiling the code to _not_ use
them, which is impossible now.

 To be precise, I suggest:

1. Add an alternative implementation of all fenv_xxx() functions except for
   fenv_precision() for which this is impossible, but which is not really
   used anywhere anyhow, using only the standard functions, with a
   condition allowing to select it at compile time (possibly activated
   automatically when SSE is used, i.e. if __SSE__ or whatever is defined).
2. Compare the results and performance of the build using the standard
   functions (but still using x87 instructions!) with the current version.
3. If both are the same, as expected, replace the current code with the
   alternative implementation and remove the condition added in (1).

 Notice that at the end of all this, you will still be building lmi using
x87 instructions in 32 bits, the only change will be that the code will be
much smaller and cleaner and the tests will now also pass in 64 bit builds.

 If you agree with the above, could you please tell me which tests should
be used for the checks in (2)?


 Finally -- and this is a much less important part, so for now you could
just stop reading here -- I also think that it could be good, but not
critical, to do the following as well:

4. Compare the results and performance of the 32 bit SSE build with the
   standard build using x87 instructions.
5. If, as hoped for, the results are still the same, but performance is
   noticeably better, consider switching to SSE in 32 bit builds too.

 Does this make more more sense?
VZ