Artyom Pavlov

I did not mean that existing compilers do it, but that AFAIK it's not explicitly forbidden. For example, an advanced LTO pass could in theory apply optimizations directly to generated...

If we are to trust the compiler to not mess with `asm!`, then I think the empty "observation" `asm!` should be sufficient. Using separate `asm!`s for every type or one...

@RalfJung Is the LTO optimization I described [above](https://github.com/RustCrypto/utils/pull/1252#issuecomment-3656845570) technically legal? Or am I being too paranoid?

@tarcieri >I think we only need one implementation of memset/bzero per architecture. I only see disadvantages when compared to the observation `asm!`. We don't win anything in language guarantees. While...

>may possibly be outsmarted by a sufficiently smart future compiler My point was that it also fully applies to `asm!`-based implementations of `memset`. For the above mentioned BOLT there may...

Yeah, `KeyInit` should not be used for public keys since it assumes that any randomly sampled key is a valid one. I am not sure that `KeyInit` is a great...

I don't think we need to make the backends generic over key size since only state initialization is different.

We have 3 options: 1) Overwrite the `KeyIvInit::new_from_slices` method to add support of 16 byte keys (e.g. see the [`blowfish`](https://github.com/RustCrypto/block-ciphers/blob/master/blowfish/src/lib.rs#L134-L141) crate). 2) Replace the `R: Rounds` with `V: Variant`, where...

@heiher I noticed that Loongarch features added in #955 differ from features supported by the [`is_loongarch_feature_detected!`](https://doc.rust-lang.org/std/arch/macro.is_loongarch_feature_detected.html) macro. Do you know why? Additionally, `rustc --target=loongarch64-unknown-linux-gnu --print=target-features` prints the following list: ```...

IMO unless there is a practical demonstration of the `asm!` approach not working, I don't think we should bother with it.