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

[Simon Dardis via llvm-dev]

(Resending,  missed llvm-dev somehow.)
> 
> 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.

This is a concern for MIPS for both correctness and quality of the generated code, and the maintenance burden regarding the number of different expansions required if they are to be expanded at the MC layer.

For example, MIPS branches have delay slots which must be filled. Filling them with nops is suboptimal for both size and performance. MIPSR6 features compact branches which don't have delay slots but do have forbidden slots which prohibit back-to-back branches (and other control flow instructions). microMIPS features compact branches in certain cases. microMIPSR6 only has compact branches but doesn't have forbidden slots.
	
Handling all those situations is currently done by the MIPS delay slot filler which knows how to reselect instructions.

MIPS needs post-ra expansion to handle the cases of stores from the same process Executing the ll/sc loop and needs the late target specific passes to clean-up the branches.

Thanks,
Simon

> 
> > 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev