On 2/19/25 1:00 AM, Robin Dapp wrote:
As I mentioned before, this may not be a good solution, as it risks missing
other
optimization opportunities. As you pointed out, we need a more general approach
to fix it. Unfortunately, while I’m still trying to find a solution, I currently
don't have any other good ideas.
Changing the rounding modes isn't common, but it's not unheard of. My
suspicion is that we need to expose the rounding mode assignment earlier
(at RTL generation time).
That may not work well with the current optimization of FRM, but I think
early exposure is the only viable path forward in my mind. Depending on
the depth of the problems it may not be something we can fix in the
gcc-15 space.
With -frounding-math CSE doesn't do the replacement. So we could argue that
a user should specify -frounding-math if they explicitly care about the
behavior. But on the other hand it's surprising if the user deliberately used
a rounding-mode setting instruction which doesn't work as intended.
Even if we wrapped those instructions in unspecs, couldn't other parts of the
program, that are compiled with the default -fno-roundin-math still lead to
unexpected results?
I don't see any other way than to "hide" the behavior from optimizers either
in order to prevent folding of such patterns.
I didn't even know the option existed! Clearly necessary if we're
using these builtins with non-default rounding modes.
One thought would be to issue a warning when using one of these builtins
with a non-default mode and -frounding-math disabled.
Another would be to implicitly turn the option on. I don't particularly
like this idea, but throwing it out there as a possibility.
jeff
