[cfe-dev] Design of FPOptions

[John McCall via cfe-dev]

On Fri, Mar 13, 2020 at 1:28 PM Serge Pavlov <sepavloff at gmail.com> wrote:
> On Fri, Mar 13, 2020 at 3:17 AM John McCall <rjmccall at gmail.com> wrote:
>> On Thu, Mar 12, 2020 at 3:51 PM Blower, Melanie I
>> <melanie.blower at intel.com> wrote:
>> > Oh I like Option 4.  I think I understand what you mean.  Clang would create and insert a “floating point region statement” into the code stream whenever we need to modify the floating point state.
>>
>> Or just some sort of PragmaStmt within a block, and some sort of
>> function-scope attribute to capture global pragma state.
>
>
> Different blocks inside the same function may have different FP environment, so FP attributes cannot have function-scope, we should associate them with CompoundStmt.

I did say that the attribute would just capture the global pragma
state, i.e. the current file-scope pragmas in effect.  You would still
need a PragmaStmt in order to express block-local pragmas, of course.
If you're saying that you could just use an implicit PragmaStmt in the
top-level CompoundStmt instead of an attribute, well, that's
theoretically possible, but you'll need to worry about constructors
(because the base-or-member-initializers are executed before the
block) and function-try-blocks.  Also, I believe you want an attribute
on the definition anyway in order to record whether it has local
pragmas, since that changes how we have to generate code for the rest
of it.

> However we need something similar for initializers and default arguments at least. Statement cannot be used here, so we need also introduce PragmaDecl. This node may be instead of PragmaStmt, if enveloped with DeclStmt.

I don't know how PragmaDecl would fix anything for initializers and
default arguments.  It's not like normal expressions can embed
pragmas.

>>   However, it would be much
>> harder for clients like the constant evaluator that might be sensitive
>> to context-sensitive evaluation settings, to the extent that some of
>> these pragmas affect formal evaluation rules (by e.g. specifying
>> static but non-standard rounding) rather than just allowing looser
>> optimization.
>
>
> I hope keeping a stack of state pragmas in Sema may alleviate this problem. It may be done by keeping only the top pragma in Sema and saving previous pragma by using RAII objects, as we already do in many cases. CodeGen also need to maintain such stack. Some function, mainly static, will require additional argument, like Sema, as some AST nodes may do not have all information about the operation they represent. The added complexity seems modest.

The constant evaluator is not part of Sema, and maintaining global
state is dangerous because we often need to try to evaluate things
that were written in different contexts.

John.