Re: additional vector function to improve register fetch performance

[Stephane Carrez <ciceron@sunchorus.France.Sun.COM>]

Hi!

> While we're talking about register fetch and stores, I had an idea the
> outher night about improving performance by adding some new functions
> to the target vector.
> 

For gdb for ChorusOS (system debug), I'm doing some prefetch to
improve performance. For each processor, I've defined a list of
"gdb important registers". I retreive the complete list when gdb asks
for one of them.

For example for Sparc, I've defined the following list:

 	sp, pc, rp, fp

So, when gdb asks for either sp or pc, I retreive these 4 registers.

In general, I've observed this is enought. For most processors
Gdb needs the sp, pc and fp (in general after each stop). I'm using this
for sparc, x86 and ppc.


> * target_prefetch_register()
> 
>   With the register cache and targets that always fetch the entire
>   register set, fetch performance is as good as can be expected.  But
>   with a target that can fetch one register at a time, GDB will issue
>   multiple single register fetches.  Due to command/response latency,
>   this has a significant performance impact.
> 
>   One way this could be addressed is to always fetch the entire
>   register set.  The remote protocol is like this, while it can set a
>   single register, there is no command to fetch one.  This approach
>   may lose when the register set is large and the number of registers
>   to be fetched is small; it may be possible to issue several single-
>   register fetches in the time for one for the entire register set.

Fetching all registers is a killer for PPC... In general, only
the pc, lr and sp are used by Gdb (ok, except for arguments/locals).

> 
>   Another is the proposed target_prefetch_register() vector function.
>   All this does is do a hint that we'll need the value of a register
>   sometime "soon".  A sequence like:
> 
>              sp = read_sp ();
>              fp = read_fp ();
>              pc = read_pc ();
>              r0 = read_register (R0_REGNUM);
> 
>   Might be changed to:
> 
>              prefetch_sp ();
>              prefetch_fp ();
>              prefetch_pc ();
>              prefetch_register (R0_REGNUM);
>              sp = read_sp ();
>              fp = read_fp ();
>              pc = read_pc ();
>              r0 = read_register (R0_REGNUM);
> 
>   (I'm assuming the prefetch* functions are added to regcache.c to do
>   whatever housekeeping is required and call the target vector
>   function).
> 
>   In a trival target, prefetch would do nothing.  In one that has a
>   async protocol, it might start fetching those registers (a callback
>   would install the value in the cache when the values were received).
>   In one that could do single, or full register set fetches, it might
>   defer fetching anything until the first "real" read was received.
>   At that time it would decide whether what type of fetch is the most
>   optimum to perform.
> 
>   The disadvantage of this is that there is no benefit if the prefetch
>   hints aren't added.  The good thing is that it keeps the interface
>   between the target independent and target specific parts of GDB
>   reasonably clean.  For contrast, imagine of a target vector function
>   that took a list of registers to read.  This (IMO) would be much
>   more difficult to use effectively.
> 
> Thoughts?  I have some partially thought ideas on how to do the same
> for register stores, but I'm going to wait until they've firmed up a
> bit before sharing.
> 
>         --jtc
>   
> -- 
> J.T. Conklin
> RedBack Networks

I like the idea of pre-fetching but I wouldn't introduce a new target
vector for that. The 'prefetch_reg' is somewhat generic. We just have
to keep a list of registers that will, soon, be required.

Then, when we really need a register, the target_fetch_register() can
look at the prefetch list that was built. It can then retrieve all of
them depending on the remote protocol.


Adding prefetch hints might be difficult and sometimes you will win nothing.
This is because when you are in the Gdb-generic code, you don't know
in advance which registers you will need. For example, when the frame is
computed, the processor specific code is called. Since this is processor
specific, you don't know which register to prefetch. Adding the pre-fetch 
in the *-tdep.c files will not help you because in general you need the 
register rigth now (ex: sparc_saved_pc_after_call, rs6000_saved_pc_after_call).


The "gdb important registers" approach is interesting in that it gives
good performance win and does not need to add the pre-fetch hints.

	Stephane


-	-	-	-	-	-	-	-	-	-
Stephane |Sun Microsystems			|
 Carrez	 |Network Service Provider Division	| http://www.sun.com
	 |6 avenue Gustave Eiffel		|
	 |F-78182, St-Quentin-en-Yvelines-Cedex |

email: Stephane.Carrez@France.Sun.COM