Comment by gingerBill

2 days ago

> the different operand sizes have a lot of side effects

Which we have massive tables for each form which track those side effects and clobbering information too.

> author/LLM

I am the author, and not an LLM.

> Tomorrow you need to pass a 128 bit int into two registers

Okay? There are no 128-bit integer registers on AMD64, ARM64, nor RISCV-64. So I have no idea what you are on about. And note they are templates, so if you want 128-bit integer support, you can just wrap that template in a procedure and handle the behaviour yourself.

5 comments

gingerBill

camel-cdr 2 days ago

I really like what you are doing here, the state of inline assembly is a similar travesty to the state of guided codegen/autovec.

On concern I have is how this maps to ARM64 syntax, because ARM64 is massively overloading all mnemonics.

For example:

    ld1d z0.h, p0/z, [x1, x2, lsl 3]
    ld1d z0.h, p0/z, [x1, z0.h, lsl 3]

Have extremely different performance characteristics, yet would map to the same code:

    ld1d dst, p0/z, [base + idx<<3]

Imo this makes reading the assembly quite bothersome. I'm already not a fan of ARM64 doing the mnemonic overloading, but at least you can figure out the operation by looking at the same line further to the right.

Also, maybe I missed it, but how are you dealing with things like the /z modifier, pre/post-increment load/store and load pair? Or things like TBL/ST4/LD4?

Oh and how are the types going to work for RVV, where the type can't be determined at compile-time in all situations?

gingerBill 1 day ago

I haven't fully thought out that syntax yet, but it's a problem with AVX-512 in terms of its predicate operands too.

My hunch would be the following:

        sve_ld1d_scalar :: asm(base: [^]u64, idx: i64, #mask pred: u16) -> (dst: #simd[vscale * 4]f32) [
                dst  = %z0,
                pred = #predicate(indirect=zeroing) %p0,
                dsth: u16 = dst,
        ] {
                ld1d dsth, pred, [base + idx<<3]
        }

        sve_ld1d_gather :: asm(base: [^]u64, #mask pred: u16) -> (dst: #simd[vscale * 4]f32) [
                dst  = %z0,
                pred = #predicate(indirect=zeroing) %p0,
                dsth: u16 = dst,
        ] {
                ld1d dsth, pred, [base + dsth<<3]
        }

So the parameter is marked as a predicate with zeroing or whatever, and then `pred` is just a normal operand as the binding section specifies everything.

This is not current behaviour yet but it I am considering it when I need to specify this for even AVX-512 and RISC-V behaviour (which has multiple different possibilities).

AshamedCaptain 1 day ago

>Which we have massive tables for each form which track those side effects and clobbering information too.

No, you have tables _of the instructions that the compiler codegen may use_. You have no tables of what someone may use inside inline assembly, because for most architectures it may not even be possible to build such tables in the first place!. That's a reason why usually you rely on the users specifying the side effects manually for these cases.

> Okay? There are no 128-bit integer registers on AMD64, ARM64, nor RISCV-64. So I have no idea what you are on about.

You have no idea why you would need to pass a 128 bit int in two registers if there are no two 128-bit integer registers? Am I missing something here?

Even rdtsc is already returning a 64-bit into two registers (another x86 idiosyncrasy I suppose), rather than "two separate return values", something the examples kind of gloss over.

gingerBill 13 hours ago
> No, you have tables _of the instructions that the compiler codegen may use_.
That's a distinction without a difference.
> ...because for most architectures it may not even be possible to build such tables in the first place!.
Name the architectures and the specific instructions; do not be hypothetical. In certain runtime-dependent cases like AVX-512, the clobbering is runtime-dependent which then can be explicitly stated by the user.
> You have no idea why you would need to pass a 128 bit int in two registers if there are no two 128-bit integer registers?
I completely understand, my point is that you would pass the two 64-bit parts into separate registers. There are no 128-bit integer registers on the platforms we care about, but if they did exist, supporting them would be trivial. So if you want to pass an 128-bit integer, it will have to be done in two registers, which is literally the point. `asm` templates are not necessarily meant to be used bare all the time, but sometimes it is better to wrap them in a procedure with the correct calling convention too (e.g. "c" or even "naked") if you want to utilizes Odin's native 128-bit integer types as part of the parameters.
- AshamedCaptain 11 hours ago
  
  > Name the architectures and the specific instructions; do not be hypothetical.
  You realize you're asking for a list of instructions that are not used by codegen but exist in the ISA? Because it is practically infinite.
  Even a plain old "in" in x86 may go from clobbering only the target registers to clobbering memory to clobbering about _every_ register (e.g. under vmware). And there's a million like these on any architecture.
  Short of generically saying all clobber everything, I really don't know how can you build a table here.
  And you are forgetting that the problem does not only extend to the compiler here, but to whoever is writing the assembly, because you may be using some register that may or may not be clobbered on depending on which 'mul' instruction operand size was used by the previous one!
  > So if you want to pass an 128-bit integer, it will have to be done in two registers, which is literally the point
  Some inline assembly syntax (e.g. Watcom) does support return an int64 as 2 registers. Are you understanding this as me asking to change the instruction to return the value in one register or something? What I'm saying is that it supports mapping its 64 bit native type (which is either two registers or always in memory, I don't care) to an inline assembly snippet that uses/returns an int64 value in two registers.
  This is just an example of the reason inline assembly syntax grows unwieldy, and there are more! Just about any 'letter' of gcc's extended ASM is another one. You seem to be trying to implement something like intrinsics here, with a very limited view of what people use inline assembly for, and that's fine, but it simply falls short, and that is why you have a hard time explaining the decisions behind inline asm syntax.