llvm dev - Jan 2020 - [cfe-dev] Calling function from non-default floating-point environment

On 7 Jan 2020, at 14:00, Kevin Neal via cfe-dev wrote:
> Right here it says that dealing with non-default modes is the job of 
> the program or programmer: “The responsibilities associated with 
> accessing the floating-point environment fall on the programmer or 
> program that does so explicitly.” It doesn’t say compiler. It also 
> hedges with words like “certain ... conventions”. If only some 
> conventions then that implies that there are other conventions that do 
> things differently and that’s OK.
>
> It explicitly calls out the programmer to solve these issues when 
> opting in to non-default FP behavior.
>
> And I say this from a company that always runs with traps enabled and 
> therefore has to deal with these FP issues. Sometimes we work around 
> traps in third party, default FP environment software. Sometimes we 
> _want_ that trap from default FP environment software because it 
> indicates a bug somewhere. We have to examine these cases individually 
> and determine what we need. It’s not the compiler’s job to protect 
> us from ourselves.
>
> Can we get a language lawyer to settle this once and for all?
I agree with your reading.  The standard is quite clear that functions 
translated under `#pragma FENV_ACCESS OFF` may assume that the control 
modes have their default settings, but it also plainly describes 
functions that are sensitive to their caller’s control modes.  If the 
control modes were meant to be implicitly managed by the implementation, 
there would have to be some way to declare the difference, but the 
standard provides no such mechanism.  Instead, the standard describes 
conventions which programmers may follow explicitly to satisfy these 
control-mode expectations.  This all leads me to the straightforward 
conclusion that it is meant to be undefined behavior to allow control to 
enter code translated under `#pragma FENV_ACCESS OFF` with non-default 
settings for the control modes (at least if that code performs any 
floating-point operations).  It would even be somewhat reasonable to 
argue that this is an intended implication of the sentence in 7.6.1p2 
beginning “If part of a program…”, although really I think it’s 
just an oversight in the drafting.

I’m not sure I *like* this language design, but it’s definitely the 
intended design.
> The next question is: should the compiler support some frontend 
> attribute to mark functions that do not require default FP mode? These 
> are functions that:
> - do not involve FP operations,
> - work correctly in any FP mode,
> - expects particular FP mode,
> - modifies FP mode,
> - probably something else.
> For such functions compiler would not generate save/restore 
> operations. We also could have several attributes if we need to 
> distinguish between these cases.
This isn’t quite what you’re asking, but:

If we’re going to do serious optimization work with code translated 
under `#pragma FENV_ACCESS ON`, we’ll want to be able to declare the 
`readonly`/`readnone` equivalents for the FP environment:

- the function will not access the FP environment at all (essentially 
meaning that it won’t perform any FP operations) or
- the function may read the FP environment, and it may change the status 
flags, but it at least won’t change the control modes.

It’s possible that the intermediate positions of “may read the FP 
environment but will not change the status flags” and “may set 
status flags, but will not read control modes” may be useful.  (I 
think the latter can only happen with calls to intrinsics like 
`fesetexcept`, but, well, those functions exist, and optimizing around 
them might matter.)

Anyway, we’ll want to do that at the IR level at least, and we’ll 
probably want to do it at the user level eventually.  But it’ll be 
awhile before we get there.  And these attributes would be quite 
different from the “allows non-default control modes” attribute that 
a different language design might need.

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

Thank you very much for the discussion.

This viewpoint on mixed FP environment simplifies development. Of course,
leaving user without compiler support is not good thing. But in future we
can invent mechanisms to alleviate the problem. For instance, a
command-line option that put save/restore call around functions, for which
FPEnv requirements are unknown. It depends on what problems will actually
arise in practical use of this feature.

Thanks,
--Serge


On Thu, Jan 9, 2020 at 1:31 PM John McCall <rjmccall at apple.com> wrote:
> On 7 Jan 2020, at 14:00, Kevin Neal via cfe-dev wrote:
>
> Right here it says that dealing with non-default modes is the job of the
> program or programmer: “The responsibilities associated with accessing the
> floating-point environment fall on the programmer or program that does so
> explicitly.” It doesn’t say compiler. It also hedges with words like
> “certain ... conventions”. If only some conventions then that implies that
> there are other conventions that do things differently and that’s OK.
>
> It explicitly calls out the programmer to solve these issues when opting
> in to non-default FP behavior.
>
> And I say this from a company that always runs with traps enabled and
> therefore has to deal with these FP issues. Sometimes we work around traps
> in third party, default FP environment software. Sometimes we _want_ that
> trap from default FP environment software because it indicates a bug
> somewhere. We have to examine these cases individually and determine what
> we need. It’s not the compiler’s job to protect us from ourselves.
>
> Can we get a language lawyer to settle this once and for all?
>
> I agree with your reading. The standard is quite clear that functions
> translated under #pragma FENV_ACCESS OFF may assume that the control
> modes have their default settings, but it also plainly describes functions
> that are sensitive to their caller’s control modes. If the control modes
> were meant to be implicitly managed by the implementation, there would have
> to be some way to declare the difference, but the standard provides no such
> mechanism. Instead, the standard describes conventions which programmers
> may follow explicitly to satisfy these control-mode expectations. This all
> leads me to the straightforward conclusion that it is meant to be undefined
> behavior to allow control to enter code translated under #pragma
> FENV_ACCESS OFF with non-default settings for the control modes (at least
> if that code performs any floating-point operations). It would even be
> somewhat reasonable to argue that this is an intended implication of the
> sentence in 7.6.1p2 beginning “If part of a program…”, although really I
> think it’s just an oversight in the drafting.
>
> I’m not sure I *like* this language design, but it’s definitely the
> intended design.
>
> The next question is: should the compiler support some frontend attribute
> to mark functions that do not require default FP mode? These are functions
> that:
> - do not involve FP operations,
> - work correctly in any FP mode,
> - expects particular FP mode,
> - modifies FP mode,
> - probably something else.
> For such functions compiler would not generate save/restore operations. We
> also could have several attributes if we need to distinguish between these
> cases.
>
> This isn’t quite what you’re asking, but:
>
> If we’re going to do serious optimization work with code translated under
#pragma
> FENV_ACCESS ON, we’ll want to be able to declare the readonly/readnone
> equivalents for the FP environment:
>
>    - the function will not access the FP environment at all (essentially
>    meaning that it won’t perform any FP operations) or
>    - the function may read the FP environment, and it may change the
>    status flags, but it at least won’t change the control modes.
>
> It’s possible that the intermediate positions of “may read the FP
> environment but will not change the status flags” and “may set status
> flags, but will not read control modes” may be useful. (I think the latter
> can only happen with calls to intrinsics like fesetexcept, but, well,
> those functions exist, and optimizing around them might matter.)
>
> Anyway, we’ll want to do that at the IR level at least, and we’ll probably
> want to do it at the user level eventually. But it’ll be awhile before we
> get there. And these attributes would be quite different from the “allows
> non-default control modes” attribute that a different language design might
> need.
>
> John.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200109/711986b7/attachment-0001.html>

On 9 Jan 2020, at 11:11, Serge Pavlov wrote:
> Thank you very much for the discussion.
>
> This viewpoint on mixed FP environment simplifies development. Of course,
> leaving user without compiler support is not good thing. But in future we
> can invent mechanisms to alleviate the problem. For instance, a
> command-line option that put save/restore call around functions, for which
> FPEnv requirements are unknown. It depends on what problems will actually
> arise in practical use of this feature.
To do this, we would need a new pragma with its own semantics.
I find it unlikely that we would pursue that.  I think it’d be
much more palatable to add a static analysis that warned about
code that appears to not be following the standard recommended
conventions.

John.