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: ARM THUMB: fundamental bug in handling of far jumps?


> 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.


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