sha2: remove RISC-V hack for unaligned loads

[newpavlov]

It simplifies the code of Zknh backends, but results in an atrocious codegen without -mno-strict-align.

Arguably, it's both an LLVM and RISC-V problem (see llvm/llvm-project#110454 and riscv/riscv-profiles#187), so it's not our responsibility to work around this stupidity. I will mention the issue in the crate docs.

Hopefully, in future we will get either this optimization, the Zicclsm handling in LLVM will change, or the proposed Oilsm extension will become the default instead of the currently useless Zicclsm.

[nazar-pc]

On target with +unaligned-scalar-mem this generated bit-identical binary for me unless I missed something obvious

[newpavlov]

Have you enabled Zkb? Without it the compiler has to use byte loads since it can not use instructions for native byte swapping.

See this godbolt link: https://rust.godbolt.org/z/x9zYx4ha8 Without +unaligned-scalar-mem or +zkb we get a bunch of lbus instead of lws.

[nazar-pc]

Yes, my target is RV64I +m,+b,+zbc,+zca,+zcb,+zcmp,+zicond,+zkn,+unaligned-scalar-mem,+relax, so it has everything necessary

[newpavlov]

Works as expected: https://rust.godbolt.org/z/nM5Y5PEbK See a bunch of lws relative to a1 after .LBB0_2.

[nazar-pc]

I'm not saying it doesn't work, but rather that this PR didn't affect the generated code with that set of features for my use case. It seems that LLVM was able to see past previous branches and reduce everything to a single case.

[newpavlov]

Yes, if LLVM is able to prove that you always pass a properly aligned buffer, then it can remove the unaligned branch completely.