Target request: x86_64 without ADX

[andres-erbsen]

It would be nice to use CryptOpt to generate plain x86_64 code that does not depend on the ADX extension, to serve as a fallback from CryptOpt-optimized fast assembly in distributed binaries. This is a requirement for deployment in BoringSSL, and I hear it may be relevant to adoption of https://github.com/mit-plv/fiat-crypto/issues/1582 as well.

I am thinking of use of CryptOpt in this context as primarily an assurance benefit, though if it's decently fast still, even better.

I would be happy to do the work for adapting CryptOpt here if you think that this would be a good first project to hack on in the CryptOpt codebase.

[dderjoel]

There is a couple things here

• [ ] we'd need switches '--no-adx' and '--no-bmi2' which would then forbid 'mulx' and 'adcx' and 'adox' instructions for the former and forbid 'bzhi' and 'shlx' instructions for the latter.
• [ ] not using mulx results in using mul, imul instead. Those implicitly use rdx and rax. Currently, as only mulx is supported, the register allocator has an option "one source argument must be in rdx", which is already a big (complex) block of code. (I wanted to refactor this ages ago already.) to support mul, we'd need an option 'one must be in rax and rdx will be overwritten'. (Preferably, the optimizer could then later choose either mul / mulx depending on where arguments are and if flags are alive). (Assemblyline also currently does not have support for mul, but that should be simple to add).
• [ ] Currently, the optimizer chooses to between add with carry and add with overflow if both flags are in the same state, (i.e. alive / killed / zero). Otherwise it uses the usable flag (i.e. chooses adcx if OF is alive, etc). This could be easily changed to always use add-with-carry. However, I have not looked into the details yet. There are many many templates for each combination of where arguments are, I'm unsure how complex that is to only use add/adc combinations.
• [ ] the bzhi is used as an alternative to and rxx, 0xfffff, can be easily turned off by now allowing alternatives in &-operations.
• [ ] the shlx can read / write to different locations with the shift amount in a register, where shl operates in place with an imm. I think that could be a rather simple change in the shift templates.

I would be happy to do the work for adapting CryptOpt here if you think that this would be a good first project to hack on in the CryptOpt codebase.

Hard to tell. I wonder if it would make sense to dive into that now or refactor beforehand to have some sort of capability system, based on which CryptOpt can emit code constructs. (Thinking of bringing this to Go-Assembly or ARM).

[andres-erbsen]

Ok, thank you for the overview! Adding support for more constrained register allocation seems to be the main challenge here, and I don't feel up to tackling it right now.