This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ARM THUMB: fundamental bug in handling of far jumps?
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Paul Koning <pkoning at equallogic dot com>
- Cc: rth at redhat dot com, avbidder at acter dot ch, gcc at gcc dot gnu dot org, Richard dot Earnshaw at arm dot com
- Date: Wed, 30 Jan 2002 11:30:51 +0000
- Subject: Re: ARM THUMB: fundamental bug in handling of far jumps?
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> Excerpt of message (sent 29 January 2002) by Richard Henderson:
> > On Tue, Jan 29, 2002 at 11:24:25AM +0100, Adrian von Bidder wrote:
> > > that's clear, as far as it is about jumping around a conditional jump. I
> > > do not understand why the above would be preferred over
> > >
> > > b[!cond] .LABEL
> > > add r2, r3
> > > .LABEL:
> > >
> > > with the latter having at least one (two, if it's a far
> > > jump-with-jump-around-the-conditional)
> >
> > Not-taken branches are normally better for performance. Might not
> > apply to the thumb though.
>
> Would this make a good target-dependent item? I know of one target
> where branches taken are definitely better than not-taken: the 68040.
>
> paul
>
Most existing ARM devices do not have branch prediction logic. However,
XScale has dynamic prediction (though I haven't studied the details) and
ARM10 uses static prediction.
The static prediction rules are trivial:
- unconditional branches are predicted taken, as are unconditional
calls to subroutines
- conditional calls to subroutines are predicted not-taken
- conditional branches are predicted taken if they are backwards and
not taken if they are forwards.
Statistical measurements show that the predictions are correct
approximately 70% of the time. Conditional execution (in ARM mode) can
often be used to reduce the number of cases where a forward branch would
be incorrectly predicted.
So it would make sense if GCC's block re-ordering code could be made to
take rules such as these into account.
R.