[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