Re: [PATCH] Fix ICE in ia64 speculation support

[Paolo Bonzini <bonzini@gnu.org>]

> OK, back to the immediate problem: speculative load appears to be trap 
> risky to the rtl analyzer due to use of (unspec) in its pattern.  UNSPEC 
> is placed into speculative loads to distinguish them from regular ones. 
>  What else, besides UNSPEC, can we use to make insn emit different asm, 
> but still have the same RTL meaning?  I can think of only one 
> alternative: use a parallel with a nop, e.g., (parallel [(set (reg) 
> (mem)) (const_int 0)]).  I think this is uglier than unspec, plus rtl 
> analyzers favor parallel less than unspec.  I appreciate any advice here.

It seems to me that only UNSPEC_VOLATILE is counted as possibly 
trapping.  The problem is than the UNSPEC recurs inside the MEM and that 
one is marked as trapping.  You could add a target hook like 
unspec_may_trap_p, with a patch like this:

Index: rtlanal.c
===================================================================
--- rtlanal.c   (revision 126191)
+++ rtlanal.c   (working copy)
@@ -2206,8 +2206,11 @@ may_trap_p_1 (rtx x, unsigned flags)
      case SCRATCH:
        return 0;

-    case ASM_INPUT:
+    case UNSPEC:
      case UNSPEC_VOLATILE:
+      return targetm.unspec_may_trap_p (x, flags);
+
+    case ASM_INPUT:
      case TRAP_IF:
        return 1;


and a default implementation of

   int j;
   if (GET_CODE (x) == UNSPEC_VOLATILE)
     return 1;

   for (j = 0; j < XVECLEN (x, 0); j++)
     if (may_trap_p_1 (XVECEXP (x, 0, j), flags))
       return 1;

The ia64 back-end could special case the unspec like this:

   if (XINT (x, 1) == ...)
     return 0;

   return default_unspec_may_trap_p (x);

(Hmm, requires making may_trap_p_1 public, it's static now).

Paolo