https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69904
--- Comment #4 from Segher Boessenkool <segher at gcc dot gnu.org> --- (In reply to ktkachov from comment #3) > (In reply to Segher Boessenkool from comment #2) > > If you disallow this memory clobber from being copied (via the > > cannot_copy_insn_p hook), do you then get what you want? > > Catching the memory barrier pattern in cannot_copy_insn_p does indeed get > the same sequence as GCC 5. Good to hear. This, together with this pattern being a very late split as you say, sounds to me like a good way forward. Probably make some special unspec for this to not pessimise other barrier uses. > But I don't see documentation for it in tm.texi ? It is DEFHOOK_UNDOC in target.def, although it does have documentation. It is the only undoc hook there that does not say "documenting this requires a GFDL license grant". Maybe just an oversight. The doc is a trivial one-liner anyway. > Considering that the memory barrier insn is represented as a clobber of a > BLKmode MEM doesn't that conceptually mean that it potentially clobbers all > of memory and thus no memory operations should be moved past it? Yes, but shrink-wrapping isn't actually moving any instructions; it decides where to put *new* instructions. Putting the prologue later than some barrier is perfectly well and good in general, and quite beneficial.
