[PATCH] Use MOVE_BARRIER instead of TRUE_BARRIER for jumps.

Vladimir N. Makarov vmakarov@redhat.com
Fri Nov 2 22:18:00 GMT 2007


Alexander Monakov wrote:

> Hi.
>
> This patch "demotes" reg_pending_barrier from TRUE_BARRIER to 
> MOVE_BARRIER  for JUMP_P insns followed by a BARRIER, so that later 
> dependencies between  insns and such jump will be marked as anti 
> instead of true.  This allows  to schedule some insns on the same 
> processor cycle as jump, possibly  improving performance.
>
> The current behaviour was introduced by this patch:  
> http://gcc.gnu.org/ml/gcc-patches/2003-04/msg00410.html , fixing a  
> reported wrong-code bug on an architecture where scheduling a set of 
> a  register and a return using that register was prohibited.  In the 
> original  report and on ia64 function return is a (parallel (return; 
> use REG)), so  we need to make sure that true dependencies are created 
> between setters of  REG and this return insn.  To achieve that, we can 
> make "else" part of "if  (reg_pending_barrier)" unconditional.  
> Finally, ia64 back-end might be  taught that latency between REG 
> setter and return is 0 (Intel's Itanium 2  docs explicitly state that 
> branches that (implicitly) use registers see  values written on the 
> same cycle), but I decided not to pursue this, as  this is not likely 
> to improve anything.
>
Indeed, the patch is a better solution of the problem.  Although it has 
one drawback which is a processing some dependencies twice when a 
barrier is present.   But it is too rare case.

> Bootstrapped and regtested on ia64-linux.  OK for trunk?
>
Yes, that is ok.  Thanks for the patch, Alexander.

As Maxim wrote, please check the indentation.  Sometimes weird 
indentation in a patch is a result of tabs (it is better to untabify 
file first and then do diff).



More information about the Gcc-patches mailing list