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

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.

On the LLVM side of things there are a few significant holes. As you've
noticed, the FP to integer conversions operations still need intrinsics, as do
fcmp, fptrunc, and fpext. There are probably others that I'm overlooking.
The FP to SI conversion has an additional wrinkle that needs to be worked out in
that the default lowering of this conversion to machine instructions is not
exception safe.

In general, the current "strict FP" handling stops at instruction
selection. At the MachineIR level we don't currently have a mechanism to
prevent inappropriate optimizations based on floating point constraints, or
indeed to convey such constraints to the backend. Implicit register use modeling
may provide some restriction on some architectures, but this is definitely
lacking for X86 targets. On the other hand, I'm not aware of any specific
current problems, so in many cases we may "get lucky" and have the
correct thing happen by chance. Obviously that's not a viable long term
solution. I have a rough plan for adding improved register modeling to the X86
backend, which should take care of instruction scheduling issues, but we'd
still need a mechanism to prevent constant folding optimizations and such.

As for what you could begin work on, it should be a fairly straight-forward task
to implement the intrinsics for fptosi, fptoui, fcmp, fptrunc, and fpext. That
would be a gentle introduction. Beyond that, it would be very helpful to have
some pathfinding work done to solidify exactly what the remaining shortcomings
are. I have a patch somewhere (stale by now, but I could refresh it pretty
easily) that unconditionally converts all FP operations to the equivalent
constrained intrinsics. You could use that to do testing and find out what's
broken.

Thanks,
Andy


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

On Thu, Aug 31, 2017 at 05:03:17PM -0500, Hal Finkel via cfe-dev
wrote:
>    To be clear, we've had several extensive discussions about this, on
and
>    off list, and Andy has started adding the corresponding intrinsics into
>    the IR. There was a presumption about a lack of mixing, however, and we
>    do need to work out how to prevent mixing the native IR operations with
>    the intrinsics (although, perhaps we just did that).
>     -Hal
What's the current status of this work? My employeer very much needs this
work done sooner rather than later, and I've been tasked with helping make
it happen.

What, exactly, still needs to be done to complete this work? I've seen some
of the discussions about it, and I've seen the documentation on the new llvm
constrained floating point intrinsics. But clang I don't think supports them
yet, fptosi is not on the list anyway, and I'm not sure what else is needed.
So I'm asking, what all is needed and what can I work on to move this
forward?

Is there any work in progress code that anyone would be willing to share?
For example, any code using the new intrinsics? Andy?


The specific case we're running into today is that we have code being
reordered in ways that trigger traps when handling a NaN. This code:

#include <math.h>

int foo(double d) {
   int x = (!isnan(d) ? (int)d : 45);
   return x;
}

... becomes this:

define signext i32 @foo(double) local_unnamed_addr #0 !dbg !10 {
  tail call void @llvm.dbg.value(metadata double %0, i64 0, metadata !15,
metadata !17), !dbg !18
  %2 = tail call signext i32 @__isnan(double %0) #3, !dbg !19
  %3 = icmp eq i32 %2, 0, !dbg !19
  %4 = fptosi double %0 to i32, !dbg !20
  %5 = select i1 %3, i32 %4, i32 45, !dbg !19
  tail call void @llvm.dbg.value(metadata i32 %5, i64 0, metadata !16, metadata
!17), !dbg !21
  ret i32 %5, !dbg !22
}

So the fptosi gets moved _above_ the select and the trap happens. This in code
that was written to avoid a trap in exactly this case.

We're compiling with clang 5.0.0 "-g -O1" targeting SystemZ.
-- 
Kevin P. Neal                                http://www.pobox.com/~kpn/
      'Concerns about "rights" and "ownership" of
domains are inappropriate.
 It is appropriate to be concerned about "responsibilities" and
"service"
 to the community.' -- RFC 1591, page 4: March 1994

On 8 January 2018 at 11:15, Kaylor, Andrew via llvm-dev <
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 the LLVM side of things there are a few significant holes. As
you've
> noticed, the FP to integer conversions operations still need intrinsics, as
> do fcmp, fptrunc, and fpext. There are probably others that I'm
> overlooking. The FP to SI conversion has an additional wrinkle that needs
> to be worked out in that the default lowering of this conversion to machine
> instructions is not exception safe.
>
> In general, the current "strict FP" handling stops at instruction
> selection. At the MachineIR level we don't currently have a mechanism
to
> prevent inappropriate optimizations based on floating point constraints, or
> indeed to convey such constraints to the backend. Implicit register use
> modeling may provide some restriction on some architectures, but this is
> definitely lacking for X86 targets. On the other hand, I'm not aware of
any
> specific current problems, so in many cases we may "get lucky"
and have the
> correct thing happen by chance. Obviously that's not a viable long term
> solution. I have a rough plan for adding improved register modeling to the
> X86 backend, which should take care of instruction scheduling issues, but
> we'd still need a mechanism to prevent constant folding optimizations
and
> such.
>
> As for what you could begin work on, it should be a fairly
> straight-forward task to implement the intrinsics for fptosi, fptoui, fcmp,
> fptrunc, and fpext. That would be a gentle introduction. Beyond that, it
> would be very helpful to have some pathfinding work done to solidify
> exactly what the remaining shortcomings are. I have a patch somewhere
> (stale by now, but I could refresh it pretty easily) that unconditionally
> converts all FP operations to the equivalent constrained intrinsics. You
> could use that to do testing and find out what's broken.
>
> Thanks,
> Andy
>
>
> -----Original Message-----
> From: Kevin P. Neal [mailto:kpn at neutralgood.org]
> Sent: Monday, January 08, 2018 6:41 AM
> To: Hal Finkel via cfe-dev <cfe-dev at lists.llvm.org>
> Cc: Richard Smith <richard at metafoo.co.uk>; Kaylor, Andrew <
> andrew.kaylor at intel.com>; Marcus Johnson <bumblebritches57 at
gmail.com>;
> wei.ding2 at amd.com; Bob Huemmer <bob.huemmer at sas.com>
> Subject: Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?
>
> On Thu, Aug 31, 2017 at 05:03:17PM -0500, Hal Finkel via cfe-dev wrote:
> >    To be clear, we've had several extensive discussions about
this, on
> and
> >    off list, and Andy has started adding the corresponding intrinsics
> into
> >    the IR. There was a presumption about a lack of mixing, however,
and
> we
> >    do need to work out how to prevent mixing the native IR operations
> with
> >    the intrinsics (although, perhaps we just did that).
> >     -Hal
>
> What's the current status of this work? My employeer very much needs
this
> work done sooner rather than later, and I've been tasked with helping
make
> it happen.
>
> What, exactly, still needs to be done to complete this work? I've seen
> some of the discussions about it, and I've seen the documentation on
the
> new llvm constrained floating point intrinsics. But clang I don't think
> supports them yet, fptosi is not on the list anyway, and I'm not sure
what
> else is needed. So I'm asking, what all is needed and what can I work
on to
> move this forward?
>
> Is there any work in progress code that anyone would be willing to share?
> For example, any code using the new intrinsics? Andy?
>
>
> The specific case we're running into today is that we have code being
> reordered in ways that trigger traps when handling a NaN. This code:
>
> #include <math.h>
>
> int foo(double d) {
>    int x = (!isnan(d) ? (int)d : 45);
>    return x;
> }
>
> ... becomes this:
>
> define signext i32 @foo(double) local_unnamed_addr #0 !dbg !10 {
>   tail call void @llvm.dbg.value(metadata double %0, i64 0, metadata !15,
> metadata !17), !dbg !18
>   %2 = tail call signext i32 @__isnan(double %0) #3, !dbg !19
>   %3 = icmp eq i32 %2, 0, !dbg !19
>   %4 = fptosi double %0 to i32, !dbg !20
>   %5 = select i1 %3, i32 %4, i32 45, !dbg !19
>   tail call void @llvm.dbg.value(metadata i32 %5, i64 0, metadata !16,
> metadata !17), !dbg !21
>   ret i32 %5, !dbg !22
> }
>
> So the fptosi gets moved _above_ the select and the trap happens. This in
> code that was written to avoid a trap in exactly this case.
>
> We're compiling with clang 5.0.0 "-g -O1" targeting SystemZ.
> --
> Kevin P. Neal                                http://www.pobox.com/~kpn/
>       'Concerns about "rights" and "ownership" of
domains are
> inappropriate.
>  It is appropriate to be concerned about "responsibilities" and
"service"
>  to the community.' -- RFC 1591, page 4: March 1994
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180108/165937dc/attachment.html>

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 
> <llvm-dev at lists.llvm.org <mailto: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.
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
>
>     On the LLVM side of things there are a few significant holes. As
>     you've noticed, the FP to integer conversions operations still
>     need intrinsics, as do fcmp, fptrunc, and fpext. There are
>     probably others that I'm overlooking. The FP to SI conversion has
>     an additional wrinkle that needs to be worked out in that the
>     default lowering of this conversion to machine instructions is not
>     exception safe.
>
>     In general, the current "strict FP" handling stops at
instruction
>     selection. At the MachineIR level we don't currently have a
>     mechanism to prevent inappropriate optimizations based on floating
>     point constraints, or indeed to convey such constraints to the
>     backend. Implicit register use modeling may provide some
>     restriction on some architectures, but this is definitely lacking
>     for X86 targets. On the other hand, I'm not aware of any specific
>     current problems, so in many cases we may "get lucky" and
have the
>     correct thing happen by chance. Obviously that's not a viable long
>     term solution. I have a rough plan for adding improved register
>     modeling to the X86 backend, which should take care of instruction
>     scheduling issues, but we'd still need a mechanism to prevent
>     constant folding optimizations and such.
>
>     As for what you could begin work on, it should be a fairly
>     straight-forward task to implement the intrinsics for fptosi,
>     fptoui, fcmp, fptrunc, and fpext. That would be a gentle
>     introduction. Beyond that, it would be very helpful to have some
>     pathfinding work done to solidify exactly what the remaining
>     shortcomings are. I have a patch somewhere (stale by now, but I
>     could refresh it pretty easily) that unconditionally converts all
>     FP operations to the equivalent constrained intrinsics. You could
>     use that to do testing and find out what's broken.
>
>     Thanks,
>     Andy
>
>
>     -----Original Message-----
>     From: Kevin P. Neal [mailto:kpn at neutralgood.org
>     <mailto:kpn at neutralgood.org>]
>     Sent: Monday, January 08, 2018 6:41 AM
>     To: Hal Finkel via cfe-dev <cfe-dev at lists.llvm.org
>     <mailto:cfe-dev at lists.llvm.org>>
>     Cc: Richard Smith <richard at metafoo.co.uk
>     <mailto:richard at metafoo.co.uk>>; Kaylor, Andrew
>     <andrew.kaylor at intel.com <mailto:andrew.kaylor at
intel.com>>; Marcus
>     Johnson <bumblebritches57 at gmail.com
>     <mailto:bumblebritches57 at gmail.com>>; wei.ding2 at amd.com
>     <mailto:wei.ding2 at amd.com>; Bob Huemmer <bob.huemmer at
sas.com
>     <mailto:bob.huemmer at sas.com>>
>     Subject: Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?
>
>     On Thu, Aug 31, 2017 at 05:03:17PM -0500, Hal Finkel via cfe-dev
>     wrote:
>     >    To be clear, we've had several extensive discussions about
>     this, on and
>     >    off list, and Andy has started adding the corresponding
>     intrinsics into
>     >    the IR. There was a presumption about a lack of mixing,
>     however, and we
>     >    do need to work out how to prevent mixing the native IR
>     operations with
>     >    the intrinsics (although, perhaps we just did that).
>     >     -Hal
>
>     What's the current status of this work? My employeer very much
>     needs this work done sooner rather than later, and I've been
>     tasked with helping make it happen.
>
>     What, exactly, still needs to be done to complete this work? I've
>     seen some of the discussions about it, and I've seen the
>     documentation on the new llvm constrained floating point
>     intrinsics. But clang I don't think supports them yet, fptosi is
>     not on the list anyway, and I'm not sure what else is needed. So
>     I'm asking, what all is needed and what can I work on to move this
>     forward?
>
>     Is there any work in progress code that anyone would be willing to
>     share?
>     For example, any code using the new intrinsics? Andy?
>
>
>     The specific case we're running into today is that we have code
>     being reordered in ways that trigger traps when handling a NaN.
>     This code:
>
>     #include <math.h>
>
>     int foo(double d) {
>        int x = (!isnan(d) ? (int)d : 45);
>        return x;
>     }
>
>     ... becomes this:
>
>     define signext i32 @foo(double) local_unnamed_addr #0 !dbg !10 {
>       tail call void @llvm.dbg.value(metadata double %0, i64 0,
>     metadata !15, metadata !17), !dbg !18
>       %2 = tail call signext i32 @__isnan(double %0) #3, !dbg !19
>       %3 = icmp eq i32 %2, 0, !dbg !19
>       %4 = fptosi double %0 to i32, !dbg !20
>       %5 = select i1 %3, i32 %4, i32 45, !dbg !19
>       tail call void @llvm.dbg.value(metadata i32 %5, i64 0, metadata
>     !16, metadata !17), !dbg !21
>       ret i32 %5, !dbg !22
>     }
>
>     So the fptosi gets moved _above_ the select and the trap happens.
>     This in code that was written to avoid a trap in exactly this case.
>
>     We're compiling with clang 5.0.0 "-g -O1" targeting
SystemZ.
>     --
>     Kevin P. Neal http://www.pobox.com/~kpn/
>     <http://www.pobox.com/%7Ekpn/>
>           'Concerns about "rights" and "ownership"
of domains are
>     inappropriate.
>      It is appropriate to be concerned about "responsibilities"
and
>     "service"
>      to the community.' -- RFC 1591, page 4: March 1994
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180108/b3263d2d/attachment.html>

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

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