Supporting X86 target

[mahesh-attarde]

Hi,
I was trying to play around X86 use case and looked at doc https://slothy-optimizer.github.io/slothy/tutorial/README.html#adding-a-new-microarchitecture. and code for https://github.com/slothy-optimizer/slothy/blob/main/slothy/targets/aarch64/cortex_a55.py. Looks like data is concentrated in each target.
Before I deep dive I was curious, since much of effort revolves around arm, what would be blocker ramping up for basic x86 target?

[mkannwischer]

Having a x86_64 model would be amazing and we'd happily merge it!

There is no particular blocker, I believe.
It was just not very clear to us how one would model x86 to get the best results, which is why we have not tried yet. But, frankly, none of us is very familiar with x86_64 performance optimization, so it may very well be possible to get good results.

You will first have to add a architecture target like aarch64_neon.py and then the microarchitecture target like cortex_a55.py.
Probably a few smaller issues will arise due to x86 specifics, but we can help out with those for sure.

Let us know if you have any questions!

@FloydZ was also interested in this at some point - did you get anywhere with this yet?

[mkannwischer]

Btw, we have some formally verified x86_64 assembly in https://github.com/pq-code-package/mlkem-native and https://github.com/pq-code-package/mldsa-native that could present a good target.
The formal verification would allow us to deploy the superoptimized code fairly soon.

[FloydZ]

@mahesh-attarde in my branch you find a python script which can translate the latency information from uops.info into slothys internal representation. But before I continue to fully integrate a x86 backend, I first wanted to make sure that its actually possible to superoptimize anything on x86. For this reason I spend the last month supteroptimizing various algorithms "by hand" to validate this. And can say its possible to achieve some speedups, the biggest I saw is ~15%. So implementing a x86 backend is definitely on my agenda for next year.

[mahesh-attarde]

Thank you @mkannwischer @FloydZ.

[mahesh-attarde]

Over weekend, I was playing around X86 with extension BASE, picking ideas from @FloydZ 's branch, small question on same.
With X86 there are implicit operands, is there way to model them?

[dop-amin]

Over weekend, I was playing around X86 with extension BASE, picking ideas from @FloydZ 's branch, small question on same. With X86 there are implicit operands, is there way to model them?

Hi, we support something like this for the flag register on Arm right now, where you can write modifiesFlags = True or readsFlags = True for an instruction in the architectural model.

See these parts of the code for details on how we use this:

• There's a pseudo-register type for the flags:

  slothy/slothy/targets/aarch64/aarch64_neon.py

  Line 140 in 63c92b9

  FLAGS = 5

• Annotate write to flags:

  slothy/slothy/targets/aarch64/aarch64_neon.py

  Line 2452 in 63c92b9

  modifiesFlags = True

• Add flags pseudo-register to output, if defined so:

  slothy/slothy/targets/aarch64/aarch64_neon.py

  Line 1101 in 63c92b9

  if modifiesFlags:

However, I think this approach is not ideal in your case because this would not genralize very well for all registers.

On another architecture I'm currently adding support for, I've generalized this concept a little bit such that you can just write a register name into the list of inputs/outputs, see for example

slothy/slothy/targets/otbn/otbn.py

Line 881 in 6238a45

outputs = ["Wd", "FG0"] # Writes to FG0 by default

. There FG0 is a specific register.

Following the latter approach sounds more suitable in your case, so you might be able to draw some inspiration from this for the x86 architectural model.

Does this help? Let me know if you have any more questions.