CORE-V Hardware Loop Codegen Issues

[PhilippvK]

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. (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: -

[ChunyuLiao]

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. (HWLP End now points to the first instruction after the body)
  Workaround: Use old version of RTL.
  Agree, I can't think of a better solution at the moment

• Compressed Instructions are not disabled for HWLP Body leading to Illegal Instruction Exceptions.
  Workaround: Compile for just RV32IM_XCVHWLP
  Agree, I can't think of a better solution at the moment

• 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)
  No call generated.
  memcpy: https://gcc.godbolt.org/z/b7vYsP883
  memset: https://gcc.godbolt.org/z/qYbrcvnTx
• Similarly, calls to math library functions such as __udivdi3 may be emitted by the compiler. (Probably also affecting softfloat library)
  Workaround: -
  enable m extension , no call __udivdi3: eg : https://github.com/llvm/llvm-project/blob/main/llvm/test/CodeGen/RISCV/div.ll

• 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,…
  Agree

• 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: -
  I'm sorry I didn't understand the question.

There is initial support for hwlp , however, hwlp is less tested and there are some issues that I haven't encountered yet.
Steps on how to reproduce the above issues would also be welcome!

[ChunyuLiao]

It looks like this is a common problem, and I'd welcome some comments from the gcc @MaryBennett

[ChunyuLiao]

gcc patch：https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637166.html thanks!

[lewis-revill]

Regarding memset/memcpy calls, they are only sometimes generated as straight line assembly seen within your example. In the case where the size requested is dynamic or just large we must use loops which would give us our original issue with disallowing unconditional jumps.