[PATCH] Fix ICE in ia64 speculation support

Maxim Kuvyrkov maxim@codesourcery.com
Fri Sep 21 09:18:00 GMT 2007

Vladimir Makarov wrote:
> Vladimir Makarov wrote:
>> Maxim Kuvyrkov wrote:
>>> The issue is that may_trap_p () can return different results given 
>>> normal instruction and its speculative version.  E.g., this occurs 
>>> for (set (reg:DF) (mem:DF)) and (set (reg:DF) (unspec:DF [(mem:DF)] 
>>> DATA_SPEC)).  The latter is a speculative variant of the former and 
>>> may_trap_p () always returns 'true' for the speculative version 
>>> because unspec:DF is considered a random floating point operation 
>>> that might trap.
>>> This causes an assert, that checks that a speculative insn can stay 
>>> speculative, fail.  The fix is to use original pattern when calling 
>>> may_trap_p ().
>> Sorry, I can reproduce the bug.  I've tried today repository.  No luck.
>                     ^ should be 'can not'
>> I think that right solution would be make may_trap_p to understand 
>> that the insn is speculative.  But without reproducing the bug, I can 
>> not be sure about my proposal.

Yep, the bug doesn't implicate itself on the trunk, the revision where 
it can be observed is 128037 (2007-09-02).

The right solution (and I'm working on it in my spare time), IMHO, would 
be to move the whole logic of determining if insn can be speculative to 
the backend and use instruction attributes to query for information. 
This way we will use target-provided information to answer the question 
if a particular insn can be executed with, possibly, wrong arguments 
instead of immediately falling back to the default answer 'yes, if it 
won't trap'.

At the moment the logic for determining if insn can begin speculation is 
in the backend, but logic responsible for be_in speculation is in 
machine-independent code.  You can sense a mismatch here :)

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.

At the moment though (considering Stage 3 et all), I can't come up with 
a better solution than using original pattern of speculative load for 
getting feedback from rtl analyzer.



More information about the Gcc-patches mailing list