On Fri, Sep 10, 2021 at 08:36:12PM +0200, Richard Biener wrote: > On September 10, 2021 6:24:50 PM GMT+02:00, Segher Boessenkool > <seg...@kernel.crashing.org> wrote: > >Yes, we should not call TRULY_NOOP_TRUNCATION_MODES_P for any random two > >modes: such a truncation needs to have a meaning at all, for the > >question to make any sense. Maybe we can add an assert to this macro to > >root out nonsensical callers? > > > >Btw. We have > >#define TRULY_NOOP_TRUNCATION_MODES_P(MODE1, MODE2) \ > > (targetm.truly_noop_truncation (GET_MODE_PRECISION (MODE1), \ > > GET_MODE_PRECISION (MODE2))) > >which is not optimal, either: does truncating DFmode to HFmode behave > >the same as truncating DImode to HImode, on every target? On *any* > >target, even?! > > When is it for any non-scalar integral mode? I suspect this was only > meaningful for integer modes from the start. On x86 i387 math any float mode > truncation is noop (with not doing actual truncation to inf).
And trunc on floating point modes was added later? Yeah, sounds like a good theory. So we should have an assertion in TNTMP that both modes are integral? (Scalar of course). Segher
