Re: [PATCH] Fix ICE in ia64 speculation support

[Paolo Bonzini <paolo.bonzini@lu.unisi.ch>]

Maxim Kuvyrkov wrote:
> Paolo Bonzini wrote:
>>
>>> 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 case is (set (reg) (UNSPEC:<fp_mode> (mem))), which is trapping 
> because it is a floating point operation (it doesn't even get to 
> analyzing the mem).

Huh.  So, the default definition should be:

   int j;
   if (GET_CODE (x) == UNSPEC_VOLATILE
       || (SCALAR_FLOAT_MODE_P (GET_MODE (x))
           && flag_trapping_math))
     return 1;

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

>> (Hmm, requires making may_trap_p_1 public, it's static now).
> 
> Not if default_unspec_may_trap_p () is defined in rtlanal.c .

But it is usually in targhooks.c, and anyway it may be necessary to call 
it from the hook in the future, e.g. if an unspec has two mems, and only 
one should be special cased.  Unless you want something as disgusting 
as^W^W^W like this:

    int result;
    rtx save = XVECEXP (x, 0, 0);
    XVECEXP (x, 0, 0) = const0_rtx;
    result = default_unspec_may_trap_p (x, flags);
    XVECEXP (x, 0, 0) = save;
    return result;

Paolo