On Wed, 26 Jul 2017, Jeff Law wrote: > So I think this is up to the target maintainers. I have no concerns > with enabling use of expand_asm_memory_barrier to be used outside of > optabs. So if the s390/x86 maintainers want to go forward, the optabs > changes are pre-approved.
Please see the alternative middle-end patch: https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00549.html and the recently reported related bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81316 Since we got it wrong for both fences and loads/stores on two different targets, perhaps fixing it once and for all in the middle-end is more appropriate. I hope extraneous compiler barriers can be tolerated. > The reasoning seems sound to me -- we may not need fencing at the > hardware level because it gives a certain set of guarantees, but we may > still need them at the compiler level to prevent undesirable code > motions across the fence point in the compiler. Yep - the same applies to atomic loads/stores too. They can be expanded as volatile accesses, but we need compiler barrier(s) anyway (except for those with relaxed memory model). Thanks. Alexander
