This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Improving GCC8 default option settings


On Tue, 12 Sep 2017, Wilco Dijkstra wrote:

> * Make -fno-trapping-math the default - another obvious one. From the docs:
>   "Compile code assuming that floating-point operations cannot generate 
>    user-visible traps."
>   There isn't a lot of code that actually uses user-visible traps (if any -
>   many CPUs don't even support user traps as it's an optional IEEE feature). 
>   So assuming trapping math by default is way too conservative since there is
>   no obvious benefit to users. 

"traps" here means "raising IEEE exception flags" not just "invoking trap 
handlers".  That is, -ftrapping-math disables a range of local 
transformations that would change the set of flags raised by an operation.  
(Transformations that change the nonzero number of times a flag is raised 
to a different nonzero number are always OK; that is, the possibility of a 
trap handler counting how many times it is invoked is never considered.  
Transformations that might move flag raising across function calls or asms 
that might inspect or modify the flags should not be OK, at least with a 
stricter version of -ftrapping-math that might be another option, but we 
don't have that stricter version at present; -ftrapping-math generally 
does not disable code movement, or removal of code that is dead apart from 
its effect on exception flags.)

That is, lack of trap support on processors that only support exception 
flags is not relevant to -ftrapping-math, beyond any question of whether 
-ftrapping-math should disable transformations that only affect whether an 
exact underflow exception occurs (the case where default exception 
handling does not raise the flag), if we have any such transformations 
(constant folding on exact underflow?).

It's true that a stricter version of -ftrapping-math that inhibits code 
movement and removal would probably inhibit *more* optimizations than 
-frounding-math (which is off by default), as -frounding-math only makes 
floating-point operations read thread-local state but -ftrapping-math 
makes them write it as well.

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]