> 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