This is the mail archive of the gcc-patches@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]

Re: Could not build libstdc++-v3 with --target=sh-elf


> 
> On Jan 12, 2001, Joern Rennecke <amylaar@redhat.com> wrote:
> 
> >> +	  && (jump_to_next || next_real_insn (JUMP_LABEL (prev)) == next
> >> +	      /* If relax_delay_slots() decides NEXT was redundant
> >> +		 with some previous instruction, it will have
> >> +		 redirected PREV's jump to the following insn.  */
> >> +	      || JUMP_LABEL (prev) == next_nonnote_insn (next)))
> 
> > You have to qualify this with '&& mdep_reorg_phase > SH_SHORTEN_BRANCHES1'.
> 
> Wouldn't it be a win to recognize such jumps regardless of their
> having been generated by SH_SHORTEN_BRANCHES1, and not emit additional
> alignment?

This is not speific for branches generated by SH_SHORTEN_BRANCHES1.

The point is that during SH_SHORTEN_BRANCHES1, one set of length calculations
is applied, and we want them to be no smaller than what is calculated later
on.  The 'redundant with previous insn' optimization can generally advance
the jump target omne further, so we have to handle this so that we won't
say early on we won't do an alignment and later shange our mind to add one.

Btw, another check that this artifact is likely from reorg and that
reorg definitely won't run again is that the jump is in a SEQUENCE.

Now, you do have a point that in general it could be more efficient to allow
a few insns between the label and the jump target.  As the code is currently
written, it allows a few insns between the preceding branch and the label.
It would probably make sense to allow as much insns between a preceding
branch and its jump target.

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