On September 10, 2021 6:24:50 PM GMT+02:00, Segher Boessenkool <seg...@kernel.crashing.org> wrote: >On Fri, Sep 10, 2021 at 03:58:47PM +0200, Richard Biener wrote: >> On September 10, 2021 3:30:10 PM GMT+02:00, Segher Boessenkool >> <seg...@kernel.crashing.org> wrote: >> >TRULY_NOOP_TRUNCATION does not make sense to ask if changing mode class. >> >> OK, so there's a mode class comparison missing here which should be a better >> fix than calling validate_subreg? > >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). > > >Segher
