[PATCH] D69272: Restricted variant of '#pragma STDC FENV_ACCESS'

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In D69272#1794630 <https://reviews.llvm.org/D69272#1794630>, @sepavloff wrote:

> In D69272#1793234 <https://reviews.llvm.org/D69272#1793234>, @rjmccall wrote:
>
> > In D69272#1792928 <https://reviews.llvm.org/D69272#1792928>, @sepavloff wrote:
> >
> > > @hfinkel proposed to use outlining to extract a block with the #pragma to separate function. It could be a basis for a full implementation.
> >
> >
> > I don't think outlining is a reasonable approach.  Outlining has a *lot* of other performance consequences, and we'd have to support arbitrary control flow (e.g. `goto`) in and out of the outlined function, which adds a lot of frontend complexity in pursuit of something that ought be handled at the optimizer level.
>
>
> The restriction on using the #pragma on top-level only may be considered as request for 'manual outlining'. User have to extract the piece of code that uses the pragma, solving problems like data passing and control flow.


Imposing the restriction is reasonable.  Doing a massive amount of throw-away work in IRGen in order to outline arbitrary sub-functions, control flow and all, just because optimizer support isn't ideal.  Just don't lift the restriction until you get the optimizer to a tenable position.

>> If a function has any blocks with the `#pragma`, we just need to emit the whole function as strictfp.  I believe the constrained FP intrinsics can take arguments that make them semantically equivalent to the default rule.  If we don't emit code outside of those blocks as efficiently as we would've before, well, that's seems like a solvable optimization problem.
> 
> Eventually we should do this. But now using constrained intrinsics means substantial performance drop down to O0-like level. This pragma is interesting for users who want to use it as a way to optimize their programs. For example, a user wants to enable exceptions in some part of the program to avoid multiple checks. For such users poor performance is inappropriate price. The fact that use of the pragma in a small block kills performance of entire function is counter-intuitive and can create lot of misunderstanding.

This argument is just as much an argument against outlining if not more.  Nobody would expect the compiler to implement things that way, and it is very likely to have major performance impact on the rest of the function by preventing optimization of any variable referenced from the inlined function.  LLVM is generally terrible at interprocedural optimization if it can't just inline, and you're proposing to block inlining for the same reason you want to inline.

Anyway, I don't think I agree with the premise that this pragma is interesting for users who want to optimize their programs.  Users who don't care about FP precision usually just use fast-math, or learn to isolate "fast-mathable" code into a particular translation unit; yes, they'd appreciate having finer-grained control, but it's not the major influence.  I would expect the pragma to be much more interesting to people who want to request specific rounding behavior and/or honor a requirement to respect the dynamic rounding mode, which is to say, to people adding *more* constraints to their program and thus making it harder to optimize.

> Full-fledged solution requires full support of constrained intrinsics in optimizations. It is not clear how large this work is, but odd are that it would require substantial efforts. It this case usable implementation of 'pragma STDC FE_ACCESS' would postponed. The restricted solution can be implemented much faster and it does not impede development of the full-fledged one.

If the only tenable option is outlining, I'm fine with living with the restricted pragma.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69272/new/

https://reviews.llvm.org/D69272