Re: [PATCH, dataflow]: Fix PR55845, 454.calculix miscompares on x86 AVX due to movement of vzeroupper

[Eric Botcazou <ebotcazou@adacore.com>]

> BTW, can't UNSPEC_VOLATILE be embedded deeply in the pattern?
> So volatile_insn_p (insn) && asm_noperands (PATTERN (insn)) == -1?
> But perhaps you want to treat that way only UNSPEC_VOLATILE directly in the
> pattern and all other UNSPEC_VOLATILE insns must describe in detail what
> exactly they are changing?  This really needs to be better documented.

Yes, I think that we should document that UNSPEC_Vs are full optimization 
barriers so the existing blockage insn of all ports are really blockage.
That's already what is implemented and seems non-controversial (unlike the 
volatile asms).  Something like:

Index: rtl.def
===================================================================
--- rtl.def     (revision 194946)
+++ rtl.def     (working copy)
@@ -213,7 +213,9 @@ DEF_RTL_EXPR(ASM_OPERANDS, "asm_operands
    */
 DEF_RTL_EXPR(UNSPEC, "unspec", "Ei", RTX_EXTRA)
 
-/* Similar, but a volatile operation and one which may trap.  */
+/* Similar, but a volatile operation and one which may trap.  Moreover, it's 
a
+   full optimization barrier, i.e. no instructions may be moved and no 
register
+   (hard or pseudo) or memory equivalences may be used across it.  */
 DEF_RTL_EXPR(UNSPEC_VOLATILE, "unspec_volatile", "Ei", RTX_EXTRA)
 
 /* Vector of addresses, stored as full words.  */

I'd also propose that blockage insns always be UNSPEC_Vs (that's already the 
case in practice, but the manual also lists volatile asms).

And I'm somewhat dubious about the distinction between toplevel and embedded 
UNSPEC_Vs in a pattern; IMO, that shouldn't make any difference.

-- 
Eric Botcazou