Hello, On Wed, 9 Aug 2023, Zhang, Annita via Gcc-patches wrote:
> > The question is whether you want to mandate the 16-bit floating point > > extensions. You might get better adoption if you stay compatible with > > shipping > > CPUs. Furthermore, the 256-bit tuning apparently benefits current Intel > > CPUs, > > even though they can do 512-bit vectors. > > > > (The thread subject is a bit misleading for this sub-topic, by the way.) > > > > Thanks, > > Florian > > Since 256bit and 512bit are diverged from AVX10.1 and will continue in > the future AVX10 versions, I think it's hard to keep a single version > number to cover both and increase monotonically. Hence I'd like to > suggest x86-64-v5 for 512bit and x86-64-v5-256 for 256bit, and so on. The raison d'etre for the x86-64-vX scheme is to make life sensible as distributor. That goal can only be achieved if this scheme contains only a few components that have a simple relationship. That basically means: one dimension only. If you now add a second dimension (with and without -512) we have to add another one if Intel (or whomever else) next does a marketing stunt for feature "foobar" and end up with x86-64-v6, x86-64-v6-512, x86-64-v6-1024, x86-64-v6-foobar, x86-64-v6-512-foobar, x86-64-v6-1024-foobar. In short: no. It isn't the right time anyway to assign meaning to x86-64-v5, as it wasn't the right time for assigning x86-64-v4 (as we now see). These are supposed to reflect generally useful feature sets actually shipped in generally available CPUs in the market, and be vendor independend. As such it's much too early to define v5 based purely on text documents. Ciao, Michael.
