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

Serge Pavlov via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Sun Dec 22 21:36:32 PST 2019


sepavloff added a comment.

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.

Arbitrary control flow creates problems even in the case of full support of the pragma. If exception takes place inside strictfp function call, the exception handler would operate in unknown FP environment and compiler in general cannot restore it. This is a problem to be solved.

Anyway outlining would be a temporary solution. When compiler can process constrained intrinsics as efficiently as regular nodes, the need in outlining would disappear.

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

Putting restriction on use of the pragma is of course, a temporary solution, it is not usable in all cases. But for some cases it is usable in production code. Where small pieces of code may be extracted into separate functions, this solution can provide tolerable performance loss, if most part of the program doesn't use constrained intrinsics. Warning prevents users from false expectations. Use in production code ensures further development of the feature.

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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69272





More information about the cfe-commits mailing list