On Tue, 11 Apr 2023, Richard Sandiford 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).
But then the bigger issue is tree_type_common where we agreed to bump precision from 10 to 16 bits, with bumping machine_mode from 8 to 16 we then are left with only 3 spare bits from 15 now - if the comments are correct. In tree_decl_common we have 13 unused bits. IRA allocno would also increase and it's hard_regno field looks suspiciously unaligned already (unless unsigned/signed re-aligns bitfields). > 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 > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)
