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

[Cameron McInally via cfe-dev]

On Fri, Mar 8, 2019 at 8:13 AM Dallman, John <john.dallman at siemens.com>
wrote:

> > > https://bugs.llvm.org/show_bug.cgi?id=30885
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D30885&d=DwMGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=O_4M49EtSpZ_-BQYeigzGv0P4__noMcSu2RYEjS1vKs&m=A-aoOWJQLWvbXtsXPgUQvm4HEszmHcurAWgL55WfknY&s=Ych5Hh3tYQL0Cov2Rz1mJiggcm4EvJaxSd9iVNRNgh4&e=>.
> 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.
>

The constrained intrinsics should be fairly trap-safe from IR through the
SelectionDAG. The X86 backend has not been made trap-safe yet. IMO, the
lion's share of the trap-unsafe optimizations are before the backend. You
might get lucky trying the constrained intrinsics now (maybe).

That said, performance at this point will be horrible. Perhaps worse than
-O0.


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

Understood. I also require something like this for my work. The constrained
intrinsics implementation is a step in the right direction, but there's a
long long way to go. You may be able to use it to flush out
Invalid/Overflow/Zero issues in the source, but would not be able to run
production quality code with traps enabled anytime soon.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190308/f3dcf495/attachment.html>