On Tue, Jun 30, 2026 at 1:52 AM Jeffrey Law <[email protected]> wrote: > > > > On 6/24/2026 1:38 AM, Andrea Pinski wrote: > > On Mon, Jun 22, 2026 at 2:01 AM Richard Biener > > <[email protected]> wrote: > >> On Mon, Jun 22, 2026 at 7:29 AM Eikansh Gupta > >> <[email protected]> wrote: > >>> Add a pattern for `(trunc)copysign ((extend)x, CST)`. Only the sign of > >>> CST matters, not its value, so it can be simplified to > >>> `copysign (x, +-0.0)` depending on the sign of CST. When signed zeros > >>> are not honored their sign may be lost, so `copysign (x, +-1.0)` is used > >>> instead. > >> Is it worth that trouble? Why not always use +-1.0? > > Jeff asked him to change it to be that way but I think it is not so > > useful. So yes using +-1.0 should be used. Though +1 will turn into > > ABS_EXPR anyways. > I was thinking more about the -1.0. That needs two bits set while -0.0 > is a single bit twiddle from +0.0 and is trivially synthesizable without > having to pull the value out of the constant pool. Of course if > HONOR_SIGNED_ZEROs is off, then +-1.0 is a better selectdion. > > It's not likely a big deal, so if y'all want to go with +-1.0 I'm not > going to worry much about it. I expect every design I care about to > support Zfa where those are all predefined constants.
My argument is both maintainance and the more likeliness of having bugs around signed zeros than +-1.0. Like consider (T)copysign (x, -0.) where the float mode for T does not have signed zeros but that for X has. I'm not sure we correctly handle this and by extension, transform it to copysign ((T)x, -1.) or if we just miss the optimization. I also think we expand copysign (x, -REAL_CST) via bit-magic anyway. Richard. > > jeff
