>> 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. -- Regards Robin
