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

Alex Bradbury via llvm-dev llvm-dev at lists.llvm.org
Thu Jun 14 05:44:57 PDT 2018


On 14 June 2018 at 12:32, Alex Bradbury <asb at lowrisc.org> wrote:
> On 14 June 2018 at 10:28, Tim Northover via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> The problem with late expansion is that even the simplest variants add
>> some rather unpleasant pseudo-instructions, and I've never even seen
>> anyone attempt to get good CodeGen out of it (simplest example being
>> "add xD, xD, #1" in the loop for an increment but there are obviously
>> more). Doing so would almost certainly involve duplicating a lot of
>> basic arithmetic instructions into AtomicRMW variants.
>
> Let's separate the concerns here:
> 1) Quality of codegen within the LL/SC loop
>   * What is the specific concern here? The LL/SC loop contains a very
> small number of instructions, even for the masked atomicrmw case. Are
> you worried about an extra arithmetic instruction or two? Sub-optimal
> control-flow? Something else?

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. 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?

Best,

Alex


More information about the llvm-dev mailing list