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

[Serge Pavlov via llvm-dev]

Hi all,

Implementation of #pragma STDC FENV_ACCESS raises a problem: what to do if
a function is called inside a region where FP environment differs from the
default? If the function expects default FP mode it may work incorrectly in
such case.

The C2x standard draft (
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2454.pdf) states (7.6p4):

Certain programming conventions support the intended model of use for the
dynamic floating-point environment:*)
— a function call does not alter its caller’s floating-point control modes,
clear its caller’s floating point status flags, nor depend on the state of
its caller’s floating-point status flags unless the function is so
documented;
— a function call is assumed to require default floating-point control
modes, unless its documentation promises otherwise;
— a function call is assumed to have the potential for raising
floating-point exceptions, unless its documentation promises otherwise.
*) With these conventions, a programmer can safely assume default
floating-point control modes (or be unaware of them). The responsibilities
associated with accessing the floating-point environment fall on the
programmer or program that does so explicitly.


It looks like that the standard requires to call functions in default FP
mode, so inside a block where #pragma STDC FENV_ACCESS acts, each function
call should be converted into sequence:
 - store FP state,
 - set default FP state,
 - call the function,
 - restore FP state.
These save/restore instructions could be inserted by compiler. This could
be the safest solution but it complicates implementation and may impact
performance. There is also another viewpoint: it is user responsibility to
provide necessary environment and save/restore operations must be inserted
manually.

Choosing the proper way we need to take into account:
- generally it is hard for a user to be sure that a function do not depend
on FP environment. Functions that apparently do not use FP numbers (like
addition to hash table) may actually involve FP operations internally.
- function inlining occurs in IR level and the chosen solution may
potentially affect semantics of other languages (maybe Fortran?).

So the first question is: should the compiler set default FP state prior to
function calls?

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.


Thanks,
--Serge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200108/d580379e/attachment.html>