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

[Cameron McInally via cfe-dev]

On Fri, Mar 8, 2019 at 12:43 PM Dallman, John <john.dallman at siemens.com>
wrote:

> Cameron wrote:
>
>
>
> > The X86 backend has not been made trap-safe yet. IMO, the lion's share
> of the trap-unsafe optimizations
>
> > are before the backend.
>
>
>
> The x86 backend will be responsible for the paired SSE2 instructions,
> won’t it? This code uses quite a lot of divides and square roots, and
> paired instructions without care for the other half of the pair are deadly
> there.
>

The scalar constrained intrinsics would prevent vectorization, so you
hopefully wouldn't see a vector sqrt/etc instruction with scalar input(s).
I don't think the X86 backend itself would select a vector instruction for
a scalar operation (I could be wrong).

If your user/frontend is issuing a vector instruction, the user/frontend
would be responsible for inserting safe values as needed (or masking on
targets that support it).


> > You might get lucky trying the constrained intrinsics now (maybe).
>
> > That said, performance at this point will be horrible. Perhaps worse
> than -O0.
>
>
>
> Ouch.
>


> > 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.
>
>
>
> The source is under continuous development, and we have testing with traps
> active on MSVC, GCC, Solaris and AIX. They can all manage this with
> production-quality code. So we’d be looking for problems created by Clang.
> Sadly, having floating-point traps active causes actual Clang quality
> problems to be hidden in the haystack of floating-point errors.
>

Yes, I know. Only a small number of people are currently working on this.
New contributors are welcome...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190308/f24526ca/attachment.html>