<div dir="ltr">I am planning in doing in IR, but with target specific-passes (such as X86ExpandAtomicPass), that just share some of the code (possibly by having each of the target-specific passes inherit from and override a target-independent pass).<div>
<br><div>The reasons for doing it in IR are the following:</div><div>- easier sharing of target-independent code</div><div>- easier dealing with control-flow (especially useful for advanced fence elimination)</div><div>But it must be target-dependent as for example on Power a seq_cst store has a fence before it, while on ARM it has a fence both before and after it (per <a href="http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html">http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html</a>)</div>
<div><br></div><div>For this exact reason, I am planning on splitting AtomicExpandLoadLinkedPass in a target-independent and a target-dependent file: the current pass claims to be target-independent but is actually designed for ARM: for example it puts a release-fence before a seq_cst CAS, which would be unsound on Power if the backend was more agressive and using lwsync for release_fences. Since these fences are not chosen based on the LLVM fences semantics, but on the hardware memory model, I was thinking of inserting target-specific intrinsics (dmb/isb on ARM, hwsync/lwsync/isync on Power), to make it clearer that these passes are target-specific and unsound outside of their target.</div>
<div><br></div><div>Another thing I would have to move to this IR pass is the insertion of fences around atomic stores/loads when insertFencesForAtomic==true. It is currently happening in SelectionDAGBuilder, which makes it impossible to do fence elimination at the IR level.</div>
<div><br></div><div>Is it reasonable, or is there some rule against using hardware-specific intrinsics at the hardware level (or some other problem with this approach)?</div></div><div><br></div><div>Cheers,</div><div>Robin Morisset</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 7, 2014 at 11:34 PM, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> Longer term, I hope to improve the fence elimination of the ARM backend with<br>
> a kind of PRE algorithm. Both of these improvements to the ARM backend<br>
> should be fairly straightforward to port to the POWER architecture later,<br>
> and I hope to also do that.<br>
><br>
> Any reason these couldn't be done at the IR level?<br>
<br>
</div>I definitely agree here. At the time, it was a plausible idea (the<br>
barriers didn't even exist in IR most of the time). But the<br>
implementation was always going to be much more complicated and less<br>
portable than in IR, and what we actually have is very flawed in its<br>
own right (only applies to ARM mode, unmaintained,<br>
<br>
Actually, I think we decided to remove it a while back, but I haven't<br>
gotten around to it yet.<br>
<br>
Cheers.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div>