Patch: Support IA-64 speculation [1/5]

[Vladimir N. Makarov]

David Edelsohn wrote:

>>>>>>Vladimir N Makarov writes:
>>>>>>            
>>>>>>
>
>Vlad> As I see now, most of code will be used only for ia64 for now because 
>Vlad> only ia64 has insns to support control and data speculation.  In future, 
>Vlad> when we have a processor with insns supporting control and data 
>Vlad> speculation, the code could be used for the processor too.  I heard, 
>Vlad> that future intel x86, x86_64 processors might have such insns.
>
>	I understand that the goal is improving scheduling on processors
>with support for speculation, but the patch changes the general GCC
>scheduler infrastructure, not just adding hooks.  What is the measured
>effect of the patch on other architectures?
>  
>
If you look at the patch, it is very hard to implement this by hooks 
only (and I am afraid the result will be even less readable).  This is 
analogous situation to premature insn scheduling for power.  Changes 
were made in machine independent part of the compiler to implement 
premature scheduling only for specific power processor.  Still there 
will be machine dependent part for ia64 (that part will need acreview 
from Jin Wilson as an ia64 maintainer).

Code for all processors except for ia64 will be the same.  As Andrey 
wrote there is even no visible difference for bootstrap time for gcc on x86.

Although I found that patch which is trying to create more regions 
(several basic blocks scheduled as one), it will probably affect other 
ports.  In theory, it should improve the code for all processors using 
insn scheduling because it creates more opportunity for speculative insn 
moves, the code size should be the same (because haifa scheduler does 
not do insn cloning).  In practice, each processor might need tuning 
(permitting less or more speculative insn moves or in extreme cases 
preventing speculative moving for regions which were not generated 
previously).  Also in practice, the code size might be sligtly different 
mainly because of label alignment and but probably because of some 
affect to subsequent optimizations.

Vlad