[llvm-dev] Atomic LL/SC loops in llvm
JF Bastien via llvm-dev
llvm-dev at lists.llvm.org
Tue May 10 19:26:54 PDT 2016
On Tue, May 10, 2016 at 3:49 PM, James Knight <jyknight at google.com> wrote:
> Yeah, I found that info in the ARM ARM, however, it provides no
> information about forward progress guarantees. There's no subset of
> instructions, maximal length of loop, or other such info about what sorts
> of LL/SC loops can be guaranteed not to live-lock. You can infer from
> and FAQs
> <http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka8404.html> that
> at least some of the ARM implementations likely do have some kind of cache
> control delay within which your loop should fit, but that's about all I can
> The lack of documented rules is perhaps only a theoretical concern, as if
> you follow all of the rules collected from other architectures, it's a
> pretty sure bet you'll be as safe as possible on ARM and PPC too. The only
> question is if it's safe to be more lax, and e.g. allowing different branch
> sequences, or not. (And of course that'd only be interesting if there were
> an actual performance advantage to doing so).
> But, it is certainly unfortunate that there appears to be no actual
> specification which a user can rely on, as MIPS has.
True, we should probably get that clarified.
BTW, on another note, the "no taken branches" restriction from Alpha is
> explained like this:
> "Branch instructions between the LDx_L/STx_C pair may be mispredicted,
> introducing load and store instructions that evict the locked cache block.
> To prevent that from happening, there is a bit in the instruction fetcher
> that is set for a LDx_L reference and cleared on any other memory
> reference. When this bit is set, the branch predictor predicts all branches
> to fall through."
> That seems like an interesting detail. I now wonder if other architectures
> have a similar issue with a mis-predicted branch in the LL/SC loop, and how
> they deal with it.
I'm not sure we care about Alpha, the memory model sure doesn't ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev