Re: [boost] C++11 compilers and fenv

Subject: Re: [boost] C++11 compilers and fenv
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-05-06 05:48:56

On 6 May 2015 at 4:25, Damian Vicino wrote:

> I was planning to access FENV for detecting unsafe operations on the
> native floating point types and include some custom pre-post conditions
> for testing other floating types safety conditions. 

The only compiler I've ever known fenv to work right on is MSVC and 
ICC. But MSVC's FP support is extremely conservative by default, and 
a lot of people needing FP performance use /fp:fast which completely 
eliminates fenv.

I just looked up the docs and even MSVC default doesn't enable all of 
fenv. For that you need /fp:strict or even /fp:except.

> I just found today that clang++ does not support the pragma to use FENV yet.
> warning: pragma STDC FENV_ACCESS ON is not supported
> Googling a little I found out that neither does gcc.

This doesn't surprise me. fenv is very hard to optimise well. Most FP 
users would prefer undefined behaviour than very slow performance. I 
would doubt clang nor GCC will ever fully implement fenv due to 
insufficient demand.

> How are c++11 boost libraries dealing with these compiler issues? 
> I got some options in mind:
> — Implement everything using custom detections, this will work in every compiler, but it will run slower for everyone too.
> — Finding a compiler with the support, implementing the library using the FENV, and assuming compilers will support it when the library is finished and reviewed.
> — Detect somehow the FENV pragma was not processed and have 2 implementations. No idea how to detect something like this.
> 
> Had someone dealt with similar problem already?
> Is there a common approach?

Your mentor will surely advise, however I would recommend that your 
library perform bit checks of the floating point values for every 
operation. This will turn each single fp opcode into about eight 
opcodes, all of which stall the CPU for a good 30 cycles each. But 
correctness is more important than speed, and if the programmer is 
employing safe_float they surely really need correctness over 
performance.

I would also examine how ubsan implements its safe float checks to 
see if you can lift some ideas.

One x86 specific trick is to reinterpret SSE2 registers as integers 
for the bit checks, that way you don't force FP values back into 
memory and reload into GP registers every single operation. 
Performance might actually be tolerable. I would suspect you'll need 
to drop into assembler for that though, and MSVC doesn't permit 
inline assembler in x64.

I'd also loop David Bellot into this and ask what he thinks.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/