> > > What's exceedingly weird is T_N_T_M_P (DImode, SImode) isn't > > > actually a truncation! The output precision is first, the input > > > precision is second. The docs explicitly state the output precision > > > should be smaller than the input precision (which makes sense for > > > truncation). > > > > > > That's where I'd start with trying to untangle this mess. > > > > Thanks (both) for correcting my misunderstanding. > > At the very least might I suggest that we introduce a new > > TRULY_NOOP_EXTENSION_MODES_P target hook that MIPS can use for this > > purpose? It'd help reduce confusion, and keep the > > documentation/function naming correct. > > > > Yes. It is good for me. > T_N_T_M_P is a really confusion naming.
Ignore my suggestion for a new target hook. GCC already has one. You shouldn't be using TRULY_NOOP_TRUNCATION_MODES_P with incorrectly ordered arguments. The correct target hook is TARGET_MODE_REP_EXTENDED, which the MIPS backend correctly defines via mips_mode_rep_extended. It's MIPS definition of (and interpretation of) mips_truly_noop_truncation that's suspect. My latest theory is that these sign extensions should be: (set (reg:DI) (sign_extend:DI (truncate:SI (reg:DI)))) and not (set (reg:DI) (sign_extend:DI (subreg:SI (reg:DI)))) If the RTL optimizer's ever split this instruction the semantics of the SUBREG intermediate are incorrect. Another (less desirable) approach might be to use an UNSPEC.
