This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Infrastructure for long branches?



On Thursday, February 7, 2002, at 02:37 PM, lucier@math.purdue.edu wrote:

> I just filed PR target/5626 (seems to be "test gcc" day today).  The 
> problem
> is that the displacements for sparcv9 branches are shorter than the
> displacements for the "same" sparcv8 branches (19 bits versus 22 bits),
> where "same" means that they use the same assembler mnemonics but are
> actually different instructions, since the sparcv9 versions are 
> "predicted"
> branches which are predicted taken if the prediction is not explicitly
> noted in the assembley.  This reduces the jump range from
> +- 8 MB to +- 1 MB.  Similarly, sparcv9 introduces some new branches that
> have only a 16-bit displacement, with a jump range of +- 128 KB.

The opcode mnemonics are the same but the full instructions are not:

bne{,a}            label            -> bicc
bne{,a}{,pn|,pt}   %[i|x]cc,label   -> bpcc; note the %cc

At least that is how it is supposed to work.  It should not be hard to get
gcc/sparcV9 to emit the older form, although this is not desirable for
performance reasons.  If gcc has an accurate idea of how far away the
branch label is (some targets do, I'm not familiar with Sparc) it should
do this only when required, which is probably about as good as you're
going to get.  Of course, if your assembler isn't doing the right thing,
you should go fix that instead.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]