[cfe-dev] Floating-point traps on x86-64

[Dallman, John via cfe-dev]

> > https://bugs.llvm.org/show_bug.cgi?id=30885. You can work around that bug by using -march=haswell
> I’ll give it a try, although I don’t hold out much hope.

That was not my problem, which is not a surprise. That issue is about converting doubles to various long integer types, which the code I work on basically doesn’t do.

> How about expressions written with variables holding doubles and the ordinary C arithmetic operators?
> My chances of getting millions of line of code that use those re-written with intrinsics are zero;

There’s a maybe here, in that we could plausibly get our domain-specific programming language to generate intrinsics from expressions, but since the intrinsics work isn’t finished yet, that isn’t a solution for this month.

> without that, I’ll be forced to turn off floating-point traps …

If I have to turn off floating-point traps, that will cause some quality disadvantage for x86 platforms compiled with Clang vs. ones that use GCC or MSVC. ARM platforms already have that disadvantage, because most ARM processor manufacturers leave out floating-point traps. The mathematical modeller I work on is used to create, edit or store about 45% of the world’s 3D CAD data, so this is not a trivial problem.

To be clear, what I’d like is the "fpexcept.maytrap" behaviour on all floating-point arithmetic. An aspect of this that is sometimes neglected with SSE2 is the need for the compiler to only use paired SSE2 operations that can trap if both registers in the SSE2 pair contain values that were either produced during the evaluation, or set up as safe values by the compiler. When you only need one square root, traps are active, and there’s garbage in the other SSE2 register, the garbage is negative reasonably often.

I guess I’m going to go hunting through LLVM options next to see if I can find anything that suppresses the problem. If I can’t, it seem like time to turn off those traps.

I’m hesitant to report LLVM bugs for several reasons:


  *   The software is closed-source commercial code. We need to set up confidentiality agreements when we share source code with compiler manufacturers, but that’s impractical for an open-source project. So I’d have to construct examples with nothing confidential in them, which takes more time.
  *   I’m not producing finished applications, but a library which is licensed to many ISVs. They need to use compatible development tools, and worry if they can’t use the same ones. So it’s much easier to support them if we use standard distributions of Clang, from Apple Xcode and the Android NDK. That means fixes will take unpredictable lengths of time to become available to me.
  *   Floating-point traps don’t seem to be considered very important by the Clang team.

Thanks,

--
John Dallman

-----------------
Siemens Industry Software Limited is a limited company registered in England and Wales.
Registered number: 3476850.
Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190308/bab4401e/attachment.html>