rjmccall added a comment. We have a very similar problem with the constrained FP intrinsics where the use of the intrinsics anywhere in a function requires (1) an attribute to be set on the function and (2) all the other code in the function to be emitted with intrinsics. What I've been treating as the plan of record is that we'll handle this by setting an attribute on the (AST) function definition whenever we see a relevant local pragma within it. And if we're doing that anyway, I think we can use it for this as well: set them in getDefaultFunctionAttributes and then clear them off if we see the attribute.
As for the RAII objects, my biggest concern here is the amount of extra work every time we emit an FP expression when we should have already set up the default configuration correctly. In the recent refactor, we started only storing FPOptions when there are non-default options for an expression. We should be able to use that to stop retranslating FPOptions to LLVM's options on every expression. (We can consider optimizing it for consecutive operations under the same non-default settings later if it proves important.) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D80462/new/ https://reviews.llvm.org/D80462 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
