[LLVMdev] Replacing Platform Specific IR Codes with Generic Implementation and Introducing Macro Facilities
David Chisnall
David.Chisnall at cl.cam.ac.uk
Sat May 10 11:01:28 PDT 2014
On 10 May 2014, at 18:41, Tim Northover <t.p.northover at gmail.com> wrote:
>>> In my experience, CodeGen has improved with the change. ISelDAG gets
>>> to make use of more information when choosing how to do the operation:
>>> values already known to be sign/zero extended, immediates, etc.
>>
>> Yes, it's definitely an improvement in the short term, but I'm not convinced
>> by the approach in the long term. It's a useful hack that works around a
>> shortcoming in the IR, not a solution.
>
> Hmm, so it sounds like you're not actually after an IR-level LL/SC,
> but a higher-level "cmpxchg weak". Fair enough, I suppose I'd
> envisaged putting that burden on Clang.
Yes. The weak cmpxchg is what the C[++]11 memory model provides, so there's a lot of work proving soundness for various transforms involving it. Once it gets to pre-codegen IR passes, it's trivial to map a load that's paired with an weak cmpxchg to a ll / ldrex and the cmpxchg to the sc / strex. This could be a generic IR pass that is parameterised with the names of the ll / sc intrinsics (or even some architecture-agnostic intrinsics for ll / sc, since they're fairly common), but ideally the optimisation would be on something that closely resembles the memory model of the source language. There are also microarchitectural optimisations that can happen later.
In clang currently, we approximate a weak cmpxchg with a strong cmpxchg, but that approximation is not quite semantically valid for all architectures (strong cmpxchg is permitted to block, weak is not) and is not ideal for optimisation either.
David
More information about the llvm-dev
mailing list