crypto-intrinsics

[tarcieri]

With the forthcoming stabilization of inline assembly, I thought we could start putting together a crate which provides wrappers for assembly instructions which are useful for cryptography but lack proper core::arch wrappers.

More importantly, using inline assembly allows us to provide a sort of black box which LLVM will not interfere with, which is problematic using anything else besides ASM. For example, it's otherwise not possible to correctly emit CMOV instructions on x86 platforms with LLVM because the x86-cmov-conversion pass which will rewrite them as branches. For more details, see:

https://dsprenkels.com/cmov-conversion.html

[tarcieri]

ADX and MULX are also good candidates, and particularly problematic to emit outside of inline assembly due to LLVM bugs:

rust-lang/stdarch#666

Namely LLVM isn't aware of the relevant flags for these instructions and either clobbers them or doesn't properly emit them.

[newpavlov]

Interesting. Is it feasible for those intrinsics to be added to core::arch eventually? Also I wonder about fragility of flags used with ADX/MULX. If we are to chain several calls to such intrinsics, are we sure that compiler can not reorder some intrinsics clobbering the flags between those calls?

[tarcieri]

Is it feasible for those intrinsics to be added to core::arch eventually?

I think the only way would be if they used inline assembly themselves. In fact I requested as much and they seemed skeptical.

If we are to chain several calls to such intrinsics, are we sure that compiler can not reorder some intrinsics clobbering the flags between those calls?

I think it still relies on careful inspection of the generated assembly, but really the important thing IMO is that LLVM does not insert additional instructions that clobber the flags, as otherwise I think the data dependencies should take care of reordering which would affect the flags.

[tarcieri]

I was able to add this for MULX, as it requires BMI2.

I tried to do the same thing with ADX, but unfortunately:

error[E0658]: the target feature `adx` is currently unstable
  --> crypto-intrinsics/src/x86_64.rs:26:18
   |
26 | #[target_feature(enable = "adx")]
   |                  ^^^^^^^^^^^^^^

[tarcieri]

It looks like a PR to stabilize ADX stalled some time in 2019: rust-lang/rust#60109

[tarcieri]

Opened a PR to stabilize the ADX target feature here: rust-lang/rust#93745

[tarcieri]

Removed draft/WIP and slimmed the initial implementation down to just cmovz and cmovnz on x86 and x86_64 targets.

Namely I removed all ADX/MULX support as we need a solution which supports carry chains emitted as a single asm! block in order to ensure flags don't get clobbered by LLVM (which is the whole point of using ADX/MULX at all).

Potentially in the future we can add some more of the CMOVcc family, and try to come up with something like a macro solution for ADX/MULX chains which emits an asm! macro with a fully formed set of assembly instructions that comprise the entire carry chain.

If it winds up this crate only implements CMOV though, I've gone ahead and snagged the cmov crate as well, and we could potentially rename this crate to that.

[tarcieri]

I'm going to open a separate PR for a simple cmov crate, since that's the only functionality currently exposed. That might be a better place to start to keep things simple.

[newpavlov]

Can you update the CI workflow with cargo cache and minimal versions job? The latter is less needed since the crate does no have any dependencies, but I guess it's better to keep workflows consistent with each other.

[newpavlov]

Wouldn't it be better to use 2021 edition and the separate workspace trick for now? It's already done for the inout crate.

[tarcieri]

That approach is really annoying from a maintenance perspective, since each crate gets its own Cargo.lock and therefore needs its own dependabot config (although that's admittedly not really a problem here).

I'd rather attempt the "delete the toplevel Cargo.toml" trick if we were to do that, but this crate is so simple it doesn't really derive any benefits from being 2021 edition.

[tarcieri]

Here's a cmov-only crate as an alternative. I'm liking this as a reasonable place to start:

#741

[tarcieri]

Closing in favor of #741