LLVM ERROR: Unable to legalize instruction about llvm-mos

[mysterymath]

For whatever reason, these .ll files contain vector types (<16 x 18>), which we don't support yet.

rs/target/release/deps/chirp8_c64-1e21b470aaa523b3.ll

; Function Attrs: noreturn nounwind nonlazybind
define void @run(ptr noundef %mem, ptr noundef %scr) unnamed_addr #7 {
start:
...
  store <16 x i8> zeroinitializer, ptr %3, align 8, !alias.scope !63
  %4 = getelementptr inbounds %"chirp8_engine::cpu::CPU", ptr %cpu, i64 0, i32 3
  store i16 0, ptr %4, align 8, !alias.scope !63
  %5 = getelementptr inbounds %"chirp8_engine::cpu::CPU", ptr %cpu, i64 0, i32 4
  store i16 512, ptr %5, align 2, !alias.scope !63
  store <16 x i16> zeroinitializer, ptr %cpu, align 8, !alias.scope !63

[gergoerdi]

I would assume this comes from my Rust code that operates on the following struct (note the regs and stack fields):

pub type Byte = u8;
pub type Addr = u16;

pub struct CPU {
    quirks: Quirks,
    regs: [Byte; 16],
    ptr: Addr,
    pc: Addr,
    stack: [Addr; 16],
    sp: usize,
    rnd: Addr,
    timer: Byte,
    state: State,
}

So is this currently impossible to compile with llvm-mos? Is there some known workaround to force the Rust compiler to represent these fields the same way as I imagine Clang must represent uint8_t[] etc.?

[mysterymath]

Is there some known workaround to force the Rust compiler to represent these fields the same way as I imagine Clang must represent uint8_t[] etc.?

I'm afraid I'm not extremely familiar with rustc, but I do know that it at least partially resembles clang, in that there's a backend target specification that describes what kind of LLVM IR the frontend is supposed to emit for a given Rust concept.

The rust-mos implement by mrk provides a partial implementation of one copied from AVR, but it's incomplete and out of date. If I recall your blog post correctly, this was from one of the more modern rust backends, so I wouldn't be surprised if there's some vectorization stuff present in those backends. If it's possible, compiling using the AVR backend or rust-mos might give better results.