On Mon, Jul 31, 2023 at 09:46:07AM -0700, Ian Rogers wrote: > On Mon, Jul 31, 2023 at 9:06 AM Alexandre Ghiti <alexghiti@xxxxxxxxxxxx> wrote: > > I have just had the answer internally (thanks to @Brendan Sweeney): > > csr modifications can alter how the memory is accessed (satp which > > changes the address space, sum which allows/disallows userspace > > access...), so we need the memory barrier to make sure the compiler > > does not reorder the memory accesses. > > The conditions you mention shouldn't apply here though? Even if you > add a memory barrier for the compiler what is stopping the hardware > reordering loads and stores? If it absolutely has to be there then a > comment something like "There is a bug is riscv where the csrr > instruction can clobber memory breaking future reads and some how this > constraint fixes it by ... ". If the hardware doesn't know that writing to a csr can change how memory accesses are done and reorders memory accesses around that csr write, you've got a really broken piece of hardware on your hands ... I know nothing about risc-v, and maybe the definition says that you need to put a memory barrier before and/or after it in the instruction stream, but on all hardware I'm familiar with, writing to a CSR is an implicitly serialising operation.
