[cfe-dev] -fdenormal-fp-math

[Evandro Menezes via cfe-dev]

Hi, Hal.

For the benefit of all, on foil 14 in this presentation by Intel, 
https://is.gd/7Ptgwx, the issues of underflow and denormals in IEEE754 
are explained.

Here's what I found out in GCC:

On {aarch64,alpha,arm,i386,ia64,mips,sparc}, when 
{-Ofast,-ffast-math,-funsafe-math-optimizations} is specified, the file 
crtfastmath.o is added to the link line.

crtfastmath.c contains a static function with the attribute 
"constructor" that sets the appropriate flag in a control register to 
round denormals to zero.  Some targets set other bits too (like Alpha 
and i386, also to round underflows to zero, and MIPS, also to disable 
exceptions).

Sun's SPARC compiler also flushes underflows and denormals to zero when 
the option {-fast,-fnonstd,-fns} is specified.  The reason given (v. 
https://is.gd/6jxW97) is also performance degradation.

Since clang has a specific flag to guide the behavior of denormals, 
-fdenormal-fp-math, it could be used to make sure that the FPU is set to 
the same specified behavior: {ieee,preserve-sign,positive-zero}.  Again, 
specific targets might decide to imply a value other than "ieee" for 
-fdenormal-fp-math when -funsafe-math-optimizations is specified, either 
explicitly or implicitly.

Thank you,

-- 
Evandro Menezes

On 03/09/2017 06:03 PM, Hal Finkel wrote:
>
> On 03/09/2017 03:41 PM, Evandro Menezes wrote:
>> On 03/09/2017 03:20 PM, Hal Finkel wrote:
>>>
>>> On 03/09/2017 03:06 PM, Evandro Menezes via cfe-dev wrote:
>>>> Can you please clarify if -fdenormal-fp-math is implied by 
>>>> -ffast-math?  If not, shouldn't it be?
>>>
>>> Why should it be?
>> It'd make sense, since most targets hiccup when tripping at a 
>> denormal, unless they're commanded to flush them to zero by flipping 
>> a bit in a control register.
>
> This is a good point. There is certainly a non-trivial amount of 
> hardware that will dump into microcode if it needs to properly process 
> denormals.
>
>>>
>>>>   Does the start-up code, if any, perhaps in compiler-rt, enable 
>>>> the appropriate bits in the proper control register?  How can I help?
>>>
>>> No. Right now, I believe that flag is taken as a statement about 
>>> what the compiler can assume about the FP environment. It is not 
>>> something we attempt to ensure at startup. I imagine we could on 
>>> some systems (as you say, by using some startup code).
>> In GCC, though there's not equivalent option to -fdenormal-fp-math, 
>> IIRC, on some targets using -ffast-math causes the CRT start up code 
>> to enable flushing to zero. Effectively, on these targets, 
>> -ffast-math implies flushing denormals to zero.
>
> Okay, interesting.
>
>>
>> Would this GCC behavior, -ffast-math implying -fdenormal-fp-math, be 
>> interesting to carry over to Clang, if not universally, on specific 
>> targets?
>
> I think it would need to be target specific, but we could definitely 
> let -ffast-math affect how linking is done so that you pick up some 
> different startup files, or similar, on systems that provide such 
> things. The startup files are generally associated with the libc 
> implementation, however, so this might be a dual-pronged task.
>
> If you could survey the GCC implementation and see what it does for 
> this on various targets, that would certainly be a useful input to 
> this discussion.
>
>  -Hal
>
>>
>> Thank you,
>>
>