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

[Kaylor, Andrew via cfe-dev]

I know next to nothing about the AST, so I'll leave commentary on that to someone who does except to say that I don't believe there is a strong connection between Richard's suggestion and Hal's. An IRBuilder can be created anywhere (and is frequently used in the optimizer). When the front end support is implemented it may use an IRBuilder that leverages the state Hal is suggesting, but representing the pragma in the AST is, I think, more about the mechanism that will indicate how to set that state.

I will say that I like Hal's suggestion very much.

-Andy

-----Original Message-----
From: Kevin P. Neal [mailto:kpn at neutralgood.org] 
Sent: Tuesday, January 09, 2018 8:05 AM
To: via cfe-dev <cfe-dev at lists.llvm.org>
Cc: Richard Smith <richard at metafoo.co.uk>; Kaylor, Andrew <andrew.kaylor at intel.com>; Nelson, Clark <clark.nelson at intel.com>; Marcus Johnson <bumblebritches57 at gmail.com>; wei.ding2 at amd.com; llvm-dev <llvm-dev at lists.llvm.org>; Hal Finkel <hfinkel at anl.gov>; Bob Huemmer <bob.huemmer at sas.com>
Subject: Re: [cfe-dev] [llvm-dev] Why is #pragma STDC FENV_ACCESS not supported?

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

Would having the pragma be part of the AST solve problems where the pragma is in the middle of a function and shouldn't apply to source that comes before the pragma?

-- 
Kevin P. Neal                                http://www.pobox.com/~kpn/
           On the community of supercomputer fans:
"But what we lack in size we make up for in eccentricity." 
  from Steve Gombosi, comp.sys.super, 31 Jul 2000 11:22:43 -0600