Expose SIMD registers as a possible register class in asm macros

[Dominaezzz]

I want to be able to write this

#[derive(Copy, Clone, Default)]
#[repr(align(16))]
#[repr(simd)]
pub struct u8x16([u8; 16]);

let a = u8x16([1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]);
let mut dest = a;

unsafe {
    asm!(
        "EE.VADDS.S8 {dst}, {dst}, {rhs}",
        dst = inout(qreg) dest,
        rhs = in(qreg) a,
    );
}

instead of this

#[derive(Copy, Clone, Default)]
#[repr(align(16))]
#[repr(simd)]
pub struct u8x16([u8; 16]);

let a = u8x16([1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]);
let mut dest = a;

unsafe {
    asm!(
        "EE.VLD.128.IP q0, {dst}, 0",
        "EE.VLD.128.IP q1, {rhs}, 0",
        "EE.VADDS.S8 {dst}, {dst}, {rhs}",
        "EE.VST.128.IP q0, {dst}, 0",
        dst = in(reg) &mut dest.0,
        rhs = in(reg) &a.0,
    );
}

This allows me not not have to choose specific registers and leave that to the compiler.
It also leaves the job of loading/storing from/to memory to the compiler, which means will allow it to only do it when necessary, as suppose to me doing it for every single operation.
The compiler would be smart enough to recycle registers and the values in them for further operations.
Also: If the compiler/llvm auto-vectorizes for loops to use SIMD, manual register choices in asm! may conflict with the registers chosen by optimiser.

From what I see, a qreg (name pending bike-shed) register class needs adding here:

• https://github.com/esp-rs/rust/blob/esp-1.90.0.0/compiler/rustc_target/src/asm/xtensa.rs#L8
• https://github.com/esp-rs/rust/blob/esp-1.90.0.0/compiler/rustc_target/src/asm/xtensa.rs#L153
• https://github.com/espressif/llvm-project/blob/release/esp_20.x/llvm/lib/Target/Xtensa/XtensaRegisterInfo.td#L75-L84 (already added?)

I haven't figured out how to teach Rustland or LLVM about the special load and store instructions for the 128 bit registers.
I'm also not sure what to add here https://github.com/esp-rs/rust/blob/esp-1.90.0.0/compiler/rustc_target/src/asm/xtensa.rs#L43, will likely have to look upstream to see how they inject "simd types" in there.

[vxpm]

any updates on this? this seems like the only way forward for using these vector instructions, since LLVM doesn't seem to generate them at all for autovectorization and even portable-simd which uses core::intrinsics::simd generates scalar code.

the #272 PR looks pretty good to me, but it should probably be added to rust-lang#147302 (which seems to be waiting on author regarding some small frame-pointer related changes)

edit: regarding the simd intrinsics, they seem to be generating the correct LLVM IR:

use core::simd::u8x16;

#[unsafe(no_mangle)]
pub fn add(a: u8x16, b: u8x16) -> u8x16 {
    a + b
}

becomes

define dso_local void @add(ptr dead_on_unwind noalias noundef writable writeonly sret([16 x i8]) align 16 captures(none) dereferenceable(16) initializes((0, 16)) %_0, ptr dead_on_return noalias noundef readonly align 16 captures(none) dereferenceable(16) %a, ptr dead_on_return noalias noundef readonly align 16 captures(none) dereferenceable(16) %b) unnamed_addr #0 !dbg !5 {
start:
  %0 = load <16 x i8>, ptr %a, align 16, !dbg !10
  %1 = load <16 x i8>, ptr %b, align 16, !dbg !10
  %2 = add <16 x i8> %1, %0, !dbg !10
  store <16 x i8> %2, ptr %_0, align 16, !dbg !10
  ret void, !dbg !18
}

so this looks like a xtensa LLVM codegen issue...

[Dominaezzz]

No updates. I was having trouble just getting rust to build and I gave up.
I have the idea of what I want to do but lack the skill/knowledge to execute it.

It is very unlikely that I'll be coming back to take this over the finish line. I don't have the patience to figure out the llvm build errors.

This feature is more a "nice to have" for me, and not a blocker.

If you can figure out how to run and test my PR, I'd be grateful.

[vxpm]

alright, i've taken some time to explore this a little - here's the progress i've made so far:

first, in order to add support for the QR registers, LLVM needs to be taught about a new inline-asm machine constraint representing them, which it can then use to know what registers it's allowed to allocate to it. currently there is no such machine contraint.

then, rustc needs to be taught about a register class for the QR registers and what machine constraint it's associated to, plus some other things such as the types it can store in them.

this is enough to get the basic example working on the inline-asm side of things (at least that's what i believe):

error: scalar-to-vector conversion failed, possible invalid constraint for vector type
  --> src/lib.rs:12:14
   |
12 |             "EE.VADDS.S8 {dst}, {dst}, {rhs}",
   |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

rustc-LLVM ERROR: Do not know how to split this operator's operand!

turns out the QR registers have no lowering support whatsoever, so LLVM does not really know how to deal with them. plus there's other things such as how to modify calling conventions to accomodate them.. and that's where my hacking-stuff-together approach falls apart. i'm afraid only someone actually experienced with LLVM could do this.

these are my forks of espressif's rust and llvm repos:
https://github.com/vxpm/llvm-project-espressif
https://github.com/vxpm/rust-xtensa

i guess i could look at how support for the vector registers of the HIFI3 extensions are implemented and try to go from there, but i'd really like some guidance at this point. i'm going to open an issue on espressif's llvm fork.