On Sun, Dec 24, 2023, 01:18 YunQiang Su <s...@gcc.gnu.org> wrote: > Roger Sayle <ro...@nextmovesoftware.com> 于2023年12月24日周日 16:51写道： > > > > > > > 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. > > > When Richard Sandiford "hookized" truly_noop_truncation in 2017 > > https://gcc.gnu.org/legacy-ml/gcc-patches/2017-09/msg00836.html > > he mentions the inprec/outprec confusion [deciding not to add a > > gcc_assert outprec < inprec here, which might be a good idea]. > > > > The next question is whether this is just > > TRULY_NOOP_SIGN_EXTENSION_MODES_P > > or whether there are any targets that usefully ensure some modes > > are zero-extended forms of others. TRULY_NOOP_ZERO_EXTENSION... > > > > I guess ARM64 is the one TRULY_NOOP_ZERO_EXTENSION? >
I am not 100% convinced here that is true. Yes aarch64 has many zero-extend instruction and ones that ignore the top 32 bits. That is a different requirement from mips. > > My vote is that a DINS instruction that updates the most significant > > bit of an SImode value should then expand or define_insn_and_split > > with an explicit following sign-extension operation. To avoid this being > > eliminated by the RTL optimizers/combine the DINS should return a > > DImode result, with the following extension truncating it to canonical > > Is it this one? > https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626137.html > > > SImode form. This preserves the required backend invariant (and > > doesn't require tweaking machine-independent code in combine). > > SImode DINS instructions that don't/can't affect the MSB, can be a > > single SImode instruction. > > > > Yes. As most of MIPS microarchitecture, INS may have slight better > performance than DINS. > This is not true. Cavium's octeon had the same performance characteristics for dins and ins. Though I doubt that microarch matters any more. Thanks, Andrew > While, I am worrying that: will some body do something like > INS <SI_REG1>,<DI_REG2>,24,8 > In this case, if <DI_REG2> is not sign-extended, the result will be > UNPREDICTABLE. > For this, now, I prefer to use DINS and append a SLL. > > I tried to write a C code that can produce this case, but not yet > success. > > > > Cheers, > > Roger > > -- > > > > >
