On Sat, Sep 11, 2021 at 4:25 PM Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > 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. There is no contradiction between integer truncate and target is FLOAT_MODE_P, extv only cares about the bits extraction, look at code below, there's convert_extracted_bit_field which is supposed to handle non scalar integral mode. The key here is the paradoxical subreg (subreg:ext_mode (target)) is not necessarily legal, and it is problematic to call gen_lowpart directly without guaranteeing this, I still prefer to add a validate_subreg(extmode, tmode) condition. > > Richard. > > > > >Segher >
-- BR, Hongtao
