This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: Increase length of non-braf branches
- From: Nick Clifton <nickc at redhat dot com>
- To: Joern Rennecke <joern dot rennecke at superh dot com>
- Cc: aoliva at redhat dot com, gcc-patches at gcc dot gnu dot org
- Date: Tue, 31 Aug 2004 15:42:51 +0100
- Subject: Re: RFA: Increase length of non-braf branches
- References: <200408311222.i7VCM9003741@chloe.uk.w2k.superh.com>
Hi Joern,
It adjusts the "length" attribute computation in sh.md to take into
account the fact that a branch insn when "braf" is not available can
consist of 6 instructions (one 32-bit) plus one empty delay slot for
a maximum length of 16 bytes.
That doesn't make sense. The code you are patching is for the case
where a free register is available, so only two instructions should be
needed, plus a maximum of 6 bytes for the constant + alignment.
Unfilled delay slots are taken care of in ADJUST_INSN_LENGTH.
Umm, well I do not understand the SH code well enough to explain what
might be going wrong then. But I do know that with the example source
file I provided and the command line specified (with -dp added) the
compiler produces jump_compact insns like this:
mov.l r1,@-r15;
mova .L2895,r0;
mov.l @r0,r1;
add r1,r0;
mov.l @r15+,r1;
jmp @r0 ! 21398 jump_compact [length = 10]
(I have inserted extra new-lines to make the output tidier). There are
obviously 6 instructions here, so the length should be at least 12. I
arrived at a value of 16 for the length of these instruction sequences
through a process of trial and error (smaller values did not work) and
also from this comment in the body of the jump_compact insn in sh.md:
/* The length is 16 if the delay slot is unfilled. */
So, I think that something is defintely going wrong in the compiler and
if it is not the length returned by the attr defintion then I do not
know what it is. :-(
Cheers
Nick