[LLVMdev] Replacing Platform Specific IR Codes with Generic Implementation and Introducing Macro Facilities
Tim Northover
t.p.northover at gmail.com
Sat May 10 08:18:06 PDT 2014
> This isn't a great example. Having load-linked / store-conditional in the
> IR would make a number of transforms related to atomics easier. We
> currently can't correctly model the weak compare-and-exchange from
> the C[++]11 memory model and we generate terrible code for a number
> of common atomic idioms on non-x86 platforms as a result.
Actually, I really agree there. I considered it recently, but decided
to leave it as an intrinsic for now (the new IR expansion pass happens
after most optimisations so there wouldn't be much benefit, but if we
did it earlier and the mid-end understood what an ldrex/strex meant, I
could see code getting much better).
Load linked would be fairly easy (perhaps even written as "load
linked", a minor extension to "load atomic"). Store conditional would
be a bigger change since stores don't return anything at the moment;
passes may not be expecting to have to ReplaceAllUses on them.
I'm hoping to have some more time to spend on atomics soon, after this
merge business is done. Perhaps then.
I don't suppose you have any plans to port Mips to the IR-level LL/SC
expansion? Now that the infrastructure is present it's quite a
simplification (r206490 in ARM64 for example, though you need existing
target-specific intrinsics at the moment). It would be good to iron
out any ARM-specific assumptions I've made.
But it would still be a construct that probably just couldn't be used
on x86 efficiently, not really a step towards a target independent IR.
Cheers.
Tim.
More information about the llvm-dev
mailing list