[PATCH] D47587: [RISCV] Codegen support for atomic operations on RV32I

Sat Jan 15 19:33:55 PST 2022

jrtc27 added a comment.

In D47587#3245887 <https://reviews.llvm.org/D47587#3245887>, @lucascars wrote:

> In D47587#1125544 <https://reviews.llvm.org/D47587#1125544>, @asb wrote:
>
>> In D47587#1125518 <https://reviews.llvm.org/D47587#1125518>, @asb wrote:
>>
>>> Thanks for querying. I actually had been referring to an earlier draft. But even with the current draft I'm concerned that v2.0 of the ISA manual didn't specify that instr[31:28] should be ignored, meaning fence.tso may simply trap on some implementations. I'll query if anyone is tracking this behaviour across available RISC-V IP cores.
>>
>> Scratch that. Version 2.0 of the spec did indicate that implementations should ignore the zeroed fields, except it did so in an aside rather than the main text. I'll update to define and make use of fence.tso. Given the poor state of compliance testing in the RISC-V world there is some chance this will cause problems on some implementations despite what the spec says.
>
> As expected... AllWinner-D1 (Risc-V 64 single core) does not implement fence.tso and will raise SIGILL...

That'll have to be patched up in M-mode then. I guess they only tested with GCC, which lowers `atomic_thread_fence(memory_order_acq_rel)` to an extremely overly strong `fence iorw, iorw`. I believe that's the only way to get a fence.tso currently; atomic reads/writes don't permit memory_order_acq_rel, and the read-modify-writes that do just use .aqrl variants of the instructions.

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D47587/new/

https://reviews.llvm.org/D47587