[Bug rtl-optimization/69904] [6 Regression] shrink-wrapping creates weird atomic compare exchange loop on arm

["segher at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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.