This is the mail archive of the
mailing list for the GCC project.
Re: RFC: Improving GCC8 default option settings
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, nd <nd at arm dot com>
- Date: Tue, 12 Sep 2017 15:30:50 +0000
- Subject: Re: RFC: Improving GCC8 default option settings
- Authentication-results: sourceware.org; auth=none
- References: <HE1PR0801MB2058CFEE6A9C43380337A83F83690@HE1PR0801MB2058.eurprd08.prod.outlook.com>
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