Richard Earnshaw <richard.earns...@foss.arm.com> writes: > On 11/04/2023 10:46, Richard Sandiford via Gcc-patches wrote: >> <juzhe.zh...@rivai.ai> writes: >>> ARM SVE has：svint8_t, svint8x2_t, svint8x3_t, svint8x4_t >>> As far as I known, they don't have tuple type for partial vector. >> >> Yeah, there are no separate types for partial vectors, but there >> are separate modes. E.g. VNx2QI is a partial vector of QIs, >> with each QI stored in a 64-bit container. >> >> I agree with all the comments about the danger of growing the number of >> modes too much. But it looks like rtx_def should be easy to rearrange. >> Unless I'm missing something, there are less than 256 rtx codes at >> present. So one simple option would be to make the code 8 bits and >> the machine_mode 16 bits (and swap them, so that they stay well-aligned >> wrt their size). >> >> That of course would create new problem if we want more than 256 codes >> in future. But then there would be the option of a non-power-of-2 >> split (12/12 or whatever). Also, it's possible to multiplex operations >> into a single code by adding an extra operand, whereas it's harder to >> multiplex modes. >> >> Thanks, >> Richard > > The rtx code and mode are both accessed quite frequently, making them > non-native machine sizes might have impact on the performance of > accessing the fields.
Yeah, that's why I suggested that having a subcode operand would be an alternative to abandoning non-power-of-2 sizes. It seems unlikely that any new codes we add now will be so frequently used that an extra operand would be a problem in terms of either size or speed. Having a subcode operand would be very much UNSPECs today. But as it is, we've added 9 new rtx codes in the last 10 years. So even with 203 at present, with the current rate of expansion, it would be at least the 2070s before this becomes an issue. Richard
