> 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
