On September 10, 2021 11:27:16 PM GMT+02:00, Segher Boessenkool <seg...@kernel.crashing.org> wrote: >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).
No, but in the context we are talking about (bitfield extraction) obviously integer truncate is referred to, a FP truncate doesn't make sense here. So either this piece needs to ask for integer modes and then also pun to them or restrict the operation to integer modes. For source int but destination FP there might be other ways to validate whether the target can do this, but TNTMP is not it. Richard. > >Segher
