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

[Alex Bradbury via llvm-dev]

On 15 June 2018 at 12:28, Tim Northover via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On Thu, 14 Jun 2018 at 13:45, Alex Bradbury <asb at lowrisc.org> wrote:
>> I don't like to see the compiler generate code that's
>> obviously dumber than what a human would write, but in this case do we
>> really think there would be any sort of measurable impact on
>> performance?
>
> It's certainly going to be marginal, but then so is the benefit of
> late expansion.

I feel differently: to my mind there's a lot to gain by late expansion
and relatively little to lose. By expanding only the LL/SC loop late
and potentially making use of future 'asm goto' support in the future
(as James suggests) there should be minimal/no codegen impact. Output
that is guaranteed to meet the platform requirements for forward
progress with a codegen method that is resilient to the introduction
of new in-tree or out-of-tree passes is a huge win to me vs the status
quo. Although the current approach appears to work ok in practice we
know expansion in IR for LL/SC is fundamentally on shaky ground  - at
least for archs other than Hexagon.

> There's also the barrier that this genuinely is a place where people
> are willing to hand-code assembly, and go rooting around in the
> compiler's output to check we're doing what they expect even if they
> don't use assembly. The assembly is possibly mostly for historical
> reasons, but it's still out there and we want to convince people to
> move away from it.
>
> I think I'm going to try to implement that verifier pass you mentioned
> and run it across an iOS build.

That would be interesting. My concern with the verifier approach is
that it may not leave the end-user with many options if it fails. A
huge improvement on having the possibility of generating questionable
code with no way of checking of course.

Best,

Alex