CORE-V Hardware Loop Codegen Issues

Placeholder Philipp van Kempen
2024-02-23T09:03:42Z

This issue should summarize all problems I ran into when playing around with `xcvhwlp` using Core-V LLVM for compiling and Core-V RISC-V GCC for linking.

- Codegen implements behavior of original PULP Hardware Loop and is therefore not compatible with recent CV32E40P RTL changes such as [14716209ec6d09ad2d31af4a5c36a094a65d767f](https://github.com/openhwgroup/cv32e40p/commit/14716209ec6d09ad2d31af4a5c36a094a65d767f). (HWLP End now points to the first instruction after the body)
**Workaround:** Use old version of RTL.
- Compressed Instructions are not disabled for HWLP Body leading to Illegal Instruction Exceptions.
**Workaround:** Compile for just `RV32IM_XCVHWLP`
- HWLP Body may contain calls to libc such as `memset` or `memcpy` resulting in disallowed unconditional jump.
**Workaround:** Use `-ffreestanding` or `-fno-builtin` (often not an option)
- Similarly, calls to math library functions such as `__udivdi3` may be emitted by the compiler. (Probably also affecting softfloat library)
**Workaround:** -
- Compiler legalization of unsupported LLVM-IR operations such as `@llvm.smax`, `@llvm.umin`,… will expand these into a sequence of supported RISC-V instructions including conditional branches.
**Workaround:** Enable XCVALU which has implementations for `CV_MAX`,…
- Same problem as above but no trivial fix available i.e. when having a 64Bit `SRA` (artithmetic shift right) in the loop body which requires custom expansion.
**Workaround:** -