De x64-ise

[ltratt]

The main part of this PR is https://github.com/ykjit/yk/commit/ec0d82ec2068a4055c1f53f396d3e22b30143333. Hopefully the comment therein explains what's going on.

[vext01]

yksmp::Location::Register(3, ..)

What is the 3?

To answer this part, yksmp is likely mirroring the register numbering scheme used in the LLVM stackmap format, which is the DWARF convention. Registers are given abstract numbers, and each platform (or ABI?) has a mapping from abstract DWARF register number to hardware register.

The x86_64 DWARF mapping can be found in the x86_64 SysV ABI spec:

[vext01]

I didn't understand this part of the commit message:

This creates a particular challenge for the JIT IR parser. Previously we assigned every instruction to either RBX or XMM0 but that isn't going to work for very long, because optimisation passes could work out they're aliases and optimise things away. This commit uses distinct (general purpose? depends on yksmp's semantics!) registers for most types but puts floating point types on the heap

At the cost of looking dumb, what is the problem we are trying to solve here? Allowing the JIT IR syntax to express trace input register allocation decisions in a platform independent way? Would the DWARF numbers suffice? That's how LLVM stackmaps solve this.

[ltratt]

To answer this part, yksmp is likely mirroring the register numbering scheme used in the LLVM stackmap format, which is the DWARF convention

OK, so it would be cool to document this! I raise #1334 to suggest doing so.

This creates a particular challenge for the JIT IR parser. Previously we assigned every instruction to either RBX or XMM0 but that isn't going to work for very long, because optimisation passes could work out they're aliases and optimise things away. This commit uses distinct (general purpose? depends on yksmp's semantics!) registers for most types but puts floating point types on the heap At the cost of looking dumb, what is the problem we are trying to solve here? Allowing the JIT IR syntax to express trace input register allocation decisions in a platform independent way? Would the DWARF numbers suffice?

Imagine you have a trace which takes %0: i8, %1: i8 as input parameters. If you find out those both came from RBX, they alias, and you can optimise this to %0: i8 = trace_input ..., %1: i8 = %0 (i.e. ProxyInst the latter). So the best outcome for the JIT parser is to make different trace inputs look like they came from different places, as we will otherwise just test "can we optimise aliased input parameters". Previously since every input parameter either came from RBX or XMM0, we would quickly optimise them all into (at most) two parameters! This commit makes the JIT IR parser try and choose different yksmp registers/stack offsets to defeat this.

[ltratt]

@vext01 I think this is ready for squashing?

[vext01]

I posted one more small comment after you suggested to squash. If the knowledge that 6 == rbp doesn't change anything, please squash.

[ltratt]

Squashed.

[I think everything surrounding yksmp registers needs more work, but this PR mostly makes the situation less bad. And it needs a more expert eye than I to fix this stuff. I've asked Lukas to have a look when he's back as he'll probably find this stuff easy to improve.]

[vext01]

Thanks. And sorry I didn't have all the answers. I tried my best.