<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 8, 2014 at 1:49 PM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.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=""><br>
On 08/08/2014 11:42 AM, Tim Northover wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am planning in doing in IR, but with target specific-passes (such as X86ExpandAtomicPass)<br>
that just share some of the code<br>
</blockquote>
This would more normally be done via target hooks in LLVM, though the<br>
principle is sound.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But it must be target-dependent as for example on Power a<br>
seq_cst store has a fence before it, while on ARM it has a fence<br>
both before and after it (per <a href="http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html" target="_blank">http://www.cl.cam.ac.uk/~<u></u>pes20/cpp/cpp0xmappings.html</a>)<br>
</blockquote>
That certainly seems to suggest some kind of parametrisation.<br>
</blockquote></div>
An alternate way of saying this might be that both ARM and Power require the store to be fenced before and after.  On Power the fence after is implicit, where on ARM it is not.  (Is this actually correct?  I don't know either of these models well.)<br>

<br>
Could you use that framing to factor the arch specific and general parts?  I'd really love to have a generic barrier combine pass which can work on the IR semantics independent of the architecture barrier semantics.</blockquote>
<div><br></div><div>More precisely, Both ARM and Power require a barrier between every store seq_cst and every later load seq_cst (among lots of other requirements).</div><div>On Power the mapping achieves this by a full fence before every load seq_cst, whereas ARM uses a full fence after ever store seq_cst.</div>
<div><br></div><div>I would also love to have a generic barrier combine pass, but I strongly doubt it is at all possible.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote>
</blockquote></div><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is it reasonable, or is there some rule against using hardware-specific<br>
intrinsics at the hardware level (or some other problem with this approach)?<br>
</blockquote>
Lots of the changes sound like they're going in the right direction.<br>
I'd particularly pleased to see other architectures using (via<br>
whatever adaptations are necessary) the atomic expansion pass; I think<br>
that could significantly simplify other backends.<br>
<br>
I'm a little concerned about changing the "fence XYZ" conversion into<br>
target intrinsics, but it looks likely it'd be necessary for<br>
performance even if the current scheme does turn out to be correct so<br>
I say go for it!<br>
</blockquote></div>
I would say there's a burden of justification that the target intrinsic approach is substantially better performance wise.  This doesn't have to be extensive, but something should be presented. (If the generic approach is actually possible.)</blockquote>
<div><br></div><div>For one simple example: acquire loads on ARM that are followed by a dependent branch can be implemented by putting an isb fence at each target of the branch (I can lookup the reference for this if you want), which is supposedly cheaper (I am hoping to get some benchmarks on this and similar things soon). But all the C11 fences, including the acquire fence require a full dmb barrier. So it is impossible to express this optimized mapping of acquire loads in a target-independent way.</div>
</div><br></div></div>