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

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69904

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ramana.radhakrishnan at arm dot co
                   |                            |m

--- Comment #3 from ktkachov at gcc dot gnu.org ---
(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. But I don't see documentation for it in tm.texi ?

As for the single RTL insn idea, we keep the compare exchange operation as a
single insn up until after reload (to prevent the register allocator doing any
funny business with spills) and split if after reload.
We don't have precedent in the arm backend of keeping splittable insns any
further than that (for example until split4) and I don't know what splitting
predicate would look like for that.

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?