[llvm-dev] Calling function from non-default floating-point environment
Serge Pavlov via llvm-dev
llvm-dev at lists.llvm.org
Tue Jan 7 10:02:04 PST 2020
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
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
— 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
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
The next question is: should the compiler support some frontend attribute
to mark functions that do not require default FP mode? These are functions
- 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev