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. Best regards, Jin Ma > 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 > >
