On 2/19/25 11:20 PM, Xi Ruoyao wrote:
On Thu, 2025-02-20 at 10:31 +0800, Jin Ma wrote:
On Wed, 19 Feb 2025 21:53:32 +0800, Jeff Law wrote:
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.
I wasn't aware of the existence of this option either. These built-ins require
it.
I suspect that it makes certain assumptions about the rounding modes in
floating-point
calculations, such as in float_extend, which may prevent CSE optimizations.
Could
this also lead to lost optimization opportunities in other areas that don't
require
this option? I'm not sure.
I suspect that the best approach would be to define relevant
attributes (perhaps similar to -frounding-math) within specific related
patterns/built-ins
to inform optimizers we are using a rounding mode and to avoid
over-optimization.
The "special pattern" is supposed to be #pragma STDC FENV_ACCESS that
we've not implemented. See https://gcc.gnu.org/PR34678.
Not exactly. That's a discussion of what it would take to make this all
work relatively seamlessly, without the need for -frounding-math.
My comment about needing a special pattern was predicated on the
(incorrect) belief that we already had some support for this baked into
the optimizers for targets that allow adjusting the rounding mode via
asms and builtins. But I was wrong.
So the issue at hand is some of the RISC-V intrinsics depend on
-frounding-math behavior and what to do about that. We could:
1. Ignore it and tell users they need to explicitly set -frouding-math
2. Issue a diagnostic if a RISC-V intrinsic that needs rounding math is
used without -frounding-math being enabled.
3. If an intrinsic that needs rounding math is used, set -frounding-math
I tend to lean towards #3 given the state of the world right now. But I
haven't actually explored this at all to know if there are any
unexpected gotchas.
Jeff
