[llvm-dev] RFC: Atomic LL/SC loops in LLVM revisited (original) (raw)
Alex Bradbury via llvm-dev llvm-dev at lists.llvm.org
Wed Oct 17 11:47:07 PDT 2018
- Previous message: [llvm-dev] zero-size arrays
- Next message: [llvm-dev] Detecting "openmp" loop and its original bounds.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, 21 Sep 2018 at 03:06, Alex Bradbury <asb at lowrisc.org> wrote:
To update on this, everything has now landed other than D48141 which implements cmpxchg for RISC-V and introduces target-independent code to help lowering part-word cmpxchg. In response to the comments on this thread and review comments I revised the patches so that as much lowering as possible is done in AtomicExpandPass, thus maximising the potential for code reuse across different targets.
I've additionally posted https://reviews.llvm.org/D52234 which updates the AtomicExpandPass docs. If there is consensus, I think both James and I would prefer to more strongly encourage that targets avoid expanding LL/SC loops in IR on the grounds that LLVM has no way to guarantee that the generated code complies with the architecture's requirements for forward progress. I believe it would be worthwhile for the Mips backend to evaluate using AtomicExpandPass in the same way the RISC-V backend now does. It wouldn't provide a correctness benefit over the current logic, but should help reduce the amount of target-specific code for handling atomics. Tim: did you get a chance at looking at a verifier pass?
Just wanted to ping this thread given the ongoing Dev Meeting. If anyone wants to discuss atomics lowering in person, I'd be keen to do so. https://reviews.llvm.org/D48131 is still awaiting review, but once landed atomics lowering should be "complete" using this proposed strategy for the RISC-V backend.
I understand an RFC soon going to be posted for asm goto, which as James noted may allow more-efficient branching in the cmpxchg case.
Best,
Alex
- Previous message: [llvm-dev] zero-size arrays
- Next message: [llvm-dev] Detecting "openmp" loop and its original bounds.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]