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. -- Xi Ruoyao <xry...@xry111.site> School of Aerospace Science and Technology, Xidian University
