[llvm-dev] Atomic LL/SC loops in llvm

[JF Bastien via llvm-dev]

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
> erratum
> <http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/254392.html>
>  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
> find.
>
> 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...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160510/c936e468/attachment.html>