[cfe-dev] [llvm-dev] Why is #pragma STDC FENV_ACCESS not supported?

[John McCall via cfe-dev]

> On Jan 9, 2018, at 11:04 AM, Kevin P. Neal via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
>>   On 01/08/2018 07:06 PM, Richard Smith via llvm-dev wrote:
>> 
>>   On 8 January 2018 at 11:15, Kaylor, Andrew via llvm-dev
>>   <[1]llvm-dev at lists.llvm.org> wrote:
>> 
>>     Hi Kevin,
>>     Thanks for reaching out about this, and thanks especially for
>>     offering to help. I've had some other priorities that have prevented
>>     me from making progress on this recently.
>>     As far as I know, there is no support at all in clang for handling
>>     the FENV_ACCESS pragma. I have a sample patch somewhere that I
>>     created to demonstrate how the front end would create the
>>     constrained intrinsics instead of normal FP operations, but
>>     correctly implementing support for the pragma requires more front
>>     end and language expertise than I possess. I believe Clark Nelson,
>>     who does have such expertise, has this on his long term TODO list
>>     but I don't know anything about the actual timeframe when the work
>>     will begin.
>> 
>>   If you want to work on this side of things, the place to start would be
>>   teaching the lexer to recognize the attribute and produce a suitable
>>   annotation token, then teaching the parser to parse the token in the
>>   places where the pragma can appear and to track the current FENV_ACCESS
>>   state. Then you'll need to find a suitable AST representation for the
>>   pragma (I have some ideas on this, feel free to ask), both for the
>>   affected compound statements and for the affected floating-point
>>   operations, build those representations when necessary, and teach the
>>   various AST consumers (LLVM IR generation and constant expression
>>   evaluation immediately spring to mind) how to handle them.
> 
> On Mon, Jan 08, 2018 at 09:49:47PM -0600, Hal Finkel via cfe-dev wrote:
>>   FWIW, I think it would be nice for the IRBuider to have a kind of
>>   "strict FP" state, kind of like how we have a "fast math" state for
>>   adding fast-math flags, that will cause CreateFAdd and friends to
>>   produce the associated intrinsics, instead of the IR instructions, when
>>   strictness is enabled.
>>    -Hal
> 
> I've been doing compiler backend work for 17 years now, but I'm new to
> llvm. I also haven't done much front end work. So if a question seems
> obvious then that's why...
> 
> Are Richard's and Hal's suggestions different parts of the same suggestion?
> Is the "fast math" state part of the AST and therefore available to
> AST consumers that way? I wouldn't guess that since the -ffast-math option
> would be compilation wide.

fp_contract provides a very similar set of language features, with both a global flag
and a #pragma that can be used at either global or local scope to control semantics
thenceforth.  We handle that in the AST by storing FPOptions on individual arithmetic
expressions, and IRGen propagates that to the individual LLVM instructions it creates.
I think that's still the right representation for the AST here, and in fact the way fp_contract
implemented means that your job at the Sema will be very easy.  The only difference is
that IRGen can't be quite as literal because you're not tracking strictness per instruction
in the IR (I think; it's not clear to me how much of this isn't solved by using intrinsics).
Regardless, that's easy enough to handle; you can just remember the strictest semantics
you tried to use in the current function and then set that as the function-level attribute
after the function definition has been fully emitted.  Plus, if you do decide to track it
per-instruction in the future, you'll be in a good position to do so.

John.