On 07/26/2017 12:13 PM, Alexander Monakov wrote: > On Wed, 26 Jul 2017, Jeff Law wrote: >> I'm not sure what you mean by extraneous compiler barriers -- isn't the >> worst case scenario here that the target emits them as well? So there >> would be an extraneous one in that case, but that ought to be a "don't >> care". > > Yes, exactly this. > >> In the middle end patch, do we need a barrier before the fence as well? >> The post-fence barrier prevents reordering the fence with anything which >> follows the fence. But do we have to also prevent reordering the fence >> with prior instructions with any of the memory models? This isn't my >> area of expertise, so if it's dumb question, don't hesitate to let me >> know :-) > > That depends on how pessimistic we want to be with respect to backend > getting it wrong. My expectation here is that if a backend emits non-empty > RTL, the produced sequence for the fence itself acts as a compiler memory > barrier. Perhaps. But do we really want to rely on that? EMitting a scheduling barrier prior to these atomics is virtually free.
Jeff
