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. Thanks! Alexander
