[PATCH] D45576: [RFC] Allow target to handle STRICT floating-point nodes

[Hal Finkel via Phabricator via llvm-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D45576#1109596, @uweigand wrote:

> In https://reviews.llvm.org/D45576#1109543, @hfinkel wrote:
>
> > That's a good point. I'm not sure that we want to model the effects of trap handlers, however. We don't at the IR level (as we mark the intrinsics as IntrInaccessibleMemOnly), and don't want to (because otherwise we need to assume that every FP operation is like an arbitrary external function call). As a result, I don't think that we want to here either. Also, can we delete the instructions when they're dead?
>
>
> Well, we certainly have a use case where trapping exception mode needs to be supported.  (At the very least, the compiler must generate code that runs correctly in an environment where trapping mode is enabled; in particular, FP operations must not be speculated, so that we don't get spurious traps.)
>
> > Also, can we delete the instructions when they're dead?
>
> According to the C11 standard F.9.1, no:
>
> > Concern about side effects may inhibit code motion and removal of seemingly useless code. For example, in
> > 
> >   #include <fenv.h>
> >   #pragma STDC FENV_ACCESS ON
> >   void f(double x)
> >   {
> >   /* ... */
> >   for (i = 0; i < n; i++) x + 1;
> >   /* ... */
> >   }
> >   
> > 
> > 
> > x + 1 might raise floating-point exceptions, so cannot be removed. And since the loop body might not execute (maybe 0 ≥ n), x + 1 cannot be moved out of the loop. (Of course these optimizations are valid if the implementation can rule out the nettlesome cases.)
> > 
> > This specification does not require support for trap handlers that maintain information about the order or count of floating-point exceptions. Therefore, between function calls, floating-point exceptions need not be precise: the actual order and number of occurrences of floating-point exceptions (> 1) may vary from what the source code expresses. Thus, the preceding loop could be treated as
> > 
> >   if (0 < n) x + 1;
>
> Note that this applies even in default (non-trapping) exception handling mode, because removing dead operations may still change the exception status flags read out by subsequent calls to fegetexcept.


Ah, okay. That doesn't seem so bad. The fact that the number of times they're called can't be observable means, I think, that we only need to model the trapping behavior as writing (and not reading) inaccessible memory. This can't be removed or speculated, but otherwise shouldn't have undo optimization implications. Do you agree?


Repository:
  rL LLVM

https://reviews.llvm.org/D45576