Intel Begins Drafting AVX10 Plans For The LLVM/Clang Compiler

[phoronix]

Phoronix: Intel Begins Drafting AVX10 Plans For The LLVM/Clang Compiler

In addition to Intel posting initial AVX10.1 patches for the GCC compiler, Intel has also begun sorting out their AVX10 plans for the LLVM/Clang compiler stack...

https://www.phoronix.com/news/Intel-Plans-AVX10-LLVM

[spiral_23]

is this evolution or revolution of x86-64

[uid313]

I don't care for those silly AVX instructions, however I do look forward to the Intel Advanced Performance Extensions (APX), those can end up be something really refreshing for x86, and something really good that can provide major real world benefits.

But most of all, I would like Intel to just make an RISC-V CPU and do x86 emulation instead.

[ms178]

is this evolution or revolution of x86-64

For end users, it means at least two more generations of Intel CPUs without modern AVX support on their hybrid designs. And no one knows for sure if AMD adopts AVX 10.2 + APX at all and if they do (most likely), when their first implementation will hit the market. If that plays out like AVX-512, then this feature set will get relevant at the end of this decade at the earliest.

[ms178]

By the way, defining the x86-64-v4 feature level around AVX-512 seems like a big headache now. Future Intel CPUs won't be compatible with that and the newer ISA also breaks the assumption that later CPUs support all features from generations before it.

[coder]

is this evolution or revolution of x86-64

Maybe, if you're talking about ISA feature levels. However, perhaps you're actually confusing it with APX?

By the way, defining the x86-64-v4 feature level around AVX-512 seems like a big headache now.

Yes. AVX10/256 forces a fork after v3. We could end up with something like v4b. Then, what to do about APX?

Future Intel CPUs won't be compatible with that and the newer ISA also breaks the assumption that later CPUs support all features from generations before it.

Actually, Intel has said future P-core Xeons will continue to support "legacy" AVX-512. Probably all CPUs implementing AVX10/512 will do so.

[-MacNuke-]

Then, what to do about APX?

I think the best way would be to introduce a new arch, aside from i386 and x86_64-*.

[coder]

I think the best way would be to introduce a new arch, aside from i386 and x86_64-*.

Oh, but if you look at what they did with APX, they clearly went out of their way to avoid a hard split between it and regular x86-64. They even went so far as to pay the price of an extra 1-byte prefix per instruction! The advantage is that you can freely mix APX and regular x86-64 code, within the same binary. That lets it work with a mechanism like glibc's ISA feature levels.

The main wrinkle is how to define feature levels beyond v4. Do we have a v4 (AVX-512), v4b (AVX10/256), v5 (AVX-512 + AVX10/512 + APX), and a v5b (AXV10/256 + APX)? Intel really made a mess of things, by walking back 512-bit vectors.

Given all the turmoil it's causing, the least they could've done is made AVX10 support variable-length vectors, like ARM and RISC-V have done. That way, you could have a single code path that optimally utilizes both AVX10/256 and AVX10/512. Instead, their approach requires you to compile your code twice, if you want to attain the full benefits of a 512-bit CPU.

[marios]

is this evolution or revolution of x86-64

Neither, x86 has reached the stage of rot...

[-MacNuke-]

Oh, but if you look at what they did with APX, they clearly went out of their way to avoid a hard split between it and regular x86-64.

Sure. But just because you can does not mean that you should do it that way. You would also not need x86_64 feature levels in general when you argue like this. Every extension is detectable at runtime. Feature levels are just a way to say: "Fuck it, either you have it or you are out". The way feature levels are handled right now is basically a new arch, except for the kernel itself.

For APX I just say: Just make it new architecture down to the kernel.