[Cfp-interest 2806] Re: Subnormals and flush-to-zero and IEC 60559 conformance macros

[Jim Thomas]

The following remarks are mine and have not benefited from CFP discussion.

For various reasons an implementation might have controls that affect program behavior, including translation-time and execution-time controls. The implementation might make such controls available to the user, as pragmas, functions, compilation options, etc.. An implementation's claim of conformance to IEC 60559 (or to the C standard or to any other specification) needs to identify any settings for the controls needed for that conformance. Using different settings might invalidate the conformance; for example, characterization macros for default or standard modes might become invalid.

Dynamic modes should be used with particular care. C subclause 7.6 offers the following guidance regarding use of the the dynamic floating-point environment:

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

Similar conventions are applicable to a flush-to-zero mode or any dynamic mode that might be available on an implementation.

Controls for the floating-point rounding modes and flags have a standard interface. But mechanisms for controlling other constant and dynamic modes vary among implementations in syntax and semantics. This makes porting code (that is sensitive to the modes) among implementations difficult, sometimes impossible without rewriting the code. TS 18661-5 attempts to address part of this problem by specifying well-defined C extensions for constant modes for evaluation methods and optimizations (including replacing subnormal operands and/or results with zero).

- Jim Thomas



> On Jul 20, 2023, at 2:15 PM, Hans Boehm <boehm at acm.org> wrote:
> 
> [ I previously sent this to a smaller group, but would also appreciate feedback from this group as well. Was it considered that IEC 60559 conformance is essentially not determinable at compile time? ]
> 
> While discussing my WG21/SG6 proposal to deprecate fenv-based rounding in C++ (wg21.link/p2746), Matthias Kretz raised the issue of code run in flush-to-zero mode. I had thought that had largely disappeared for CPU-executed code, but it actually seems quite common on X86. Based on a quick look, ARM is similar, though RISC-V is currently not, I think.
> 
> I investigated this while trying to generate the next paper revision (which will be delayed, partly as a result). The current draft of my conclusions is below. But my overall conclusion is that this is a bit of a mess, and probably one I want to largely ignore for now. But I'd appreciate any insights you may have. (Feel free to forward, if you like. I can also post to the cfp and sg6 groups, but I wanted to ask you for feedback first.)
> 
> It appears to me that the 60559-conformance macros defined in C23 are essentially unimplementable on modern x86 platforms, because there is no way to know until runtime whether the hardware is conformant; it depends on what code was run at startup-time, or possibly later if somebody decides to switch the flush-to-zero bits in the middle. And the macros may or may not indicate what the programmer actually wants to know. I expect that some code will want to treat a 60559-except-flush-to-zero platform as conformant, and clearly some will not.
> 
> Current draft of summary for wg21.link/p2746:
> 
> It was pointed out that it is common to disable subnormals/denormals/gradual underflow on x86, and changing this locally around cr_ library calls is probably infeasible.
> 
> Further investigation showed:
> 
> Implementations other than x87 (SSE and later) commonly need software assist for gradual underflow, potentially making performance unacceptable when dealing with many near-zero values. Gcc provides the -mdaz-ftz (denormals are zero, flush to zero) flag for this purpose. It appears to be implemented entirely by including code that sets a hardware flag; constants are unaffected. 
> 
> This seems to be most commonly enabled by -ffast-math.
> 
> This mode is not IEC 60559 conformant. The C standard also  says “IEC 60559 arithmetic (with default exception handling) always treats subnormal numbers as nonzero”. Clang does not support it as an explicit flag, though -ffast-math may have a similar effect. (This seems to depend on installation details.) As one might expect, it is highly controversial. It is also brittle since it can apparently affect code not expecting to run in this mode. (See e.g. https://moyix.blogspot.com/2022/09/someones-been-messing-with-my-subnormals.html, which I found through a clang discussion.)
> 
> It is hard to make compiler-provided information about 60559 conformance accurate, given that behavior with respect to subnormals is controlled by a runtime flag. Gcc sets __STDC_IEC_559__ with -mdaz-ftz, but not with -ffast-math.
> 
> My current conclusion is that this is a bit of a mess, which we should largely try to dodge. A standard-conforming implementation should not claim to be 60559 compliant unless it can turn off flush-to-zero for those operations.
> 
> Hans
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20230722/f3445302/attachment.htm>