llvm dev - Jun 2018 - RFC: Atomic LL/SC loops in LLVM revisited

On Thu, 14 Jun 2018 at 13:45, Alex Bradbury <asb at lowrisc.org>
wrote:
> Oh I see what you're saying, it's the fact that by bypassing
> instruction selection we're missing cases where an ADDI could be
> selected rather than an ADD, which would potentially free up a
> register and save the instruction generated for materialising the
> constant.
Yes.
> 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.

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.

Cheers.

Tim.

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

(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