On Wed, Aug 9, 2023 at 4:14 PM Florian Weimer <fwei...@redhat.com> wrote: > > * Richard Biener via Gcc-patches: > > > I don’t think we can realistically change the ABI. If we could > > passing them in two 256bit registers would be possible as well. > > > > Note I fully expect intel to turn around and implement 512 bits on a > > 256 but data path on the E cores in 5 years. And it will take at > > least that time for AVX10 to take off (look at AVX512 for this and how > > they cautionously chose to include bf16 to cut off Zen4). So IMHO we > > shouldn’t worry at all and just wait and see for AVX42 to arrive. > > Yes, the direction is a bit unclear. In retrospect, we could have > defined x86-64-v4 to use 256 bit vector width, so it could eventually be > compatible with AVX10; it's also what current Intel CPUs prefer (and NOTE, avx10.x-256 also inhibit the usage of 64-bit kmask which is supposed to be only used by zmm instructions. But in theory, those 64-bit kmask intrinsics can be used standalone .i.e. kshift/kand/kor. > past, with the exception of the Xeon Phi line). But in the meantime, > AMD has started to ship CPUs that seem to prefer 512 bit vectors, > despite having a double pumped implementation. (Disclaimer: All CPU > preferences inferred from current compiler tuning defaults, not actual > experiments. 8-/) > > To me, this looks like we may have defined x86-64-v4 prematurely, and > this suggests we should wait a bit to see where things are heading. > > Thanks, > Florian >
-- BR, Hongtao
