[llvm-dev] RFC: Atomic LL/SC loops in LLVM revisited

[James Y Knight via llvm-dev]

On Fri, Jun 15, 2018 at 11:21 AM Krzysztof Parzyszek <
kparzysz at codeaurora.org> wrote:

> Hexagon has a very few restrictions on what will cause loss of a
> reservation: those are stores to the same address (a 64-bit granule) or
> any sort of exception/interrupt/system call. Other than that the
> reservation should stay. The architecture doesn't explicitly guarantee
> that though, but in the absence of the elements listed above, a program
> with LL/SC can be expected to make progress.
>
> Consequently, the best way for us to handle LL/SC would be to expand
> them early and let them be optimized as any other code. The usual
> optimization restrictions should be sufficient to prevent introduction
> of factors causing a loss of reservation.
>
> With the constraints on LL/SC varying wildly between architectures,
> maybe we should have several options available for different targets?
>

The constraints on LL/SC don't seem to vary that wildly between
architectures (except Hexagon, I guess!) -- sure, the exact details are
different, but they all (the others) have some set of requirements on the
structure of their loop which are not generally possible guarantee in a
high level abstract representation. Given that, the details of the
requirements aren't particularly relevant, they just need to be properly
adhered to when writing the target-specific code to generate the machine
instructions for the ll/sc loop.

I'm a bit skeptical that Hexagon is truly different in this regards than
all the other architectures. But, that said, I don't think it'd be at all
problematic to keep the IR-level lowering code around for Hexagon to
continue to use, even if we do migrate everything else away.

We definitely need to introduce new options alongside the current options
to start with, anyways -- at the very least simply to allow migrating each
architecture separately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180615/67f2a937/attachment.html>