[RFA] sh-tdep.c: optimize fv_reg_base_num and dr_reg_base_num

[RFA] sh-tdep.c: optimize fv_reg_base_num and dr_reg_base_num

[Corinna Vinschen]

Hi,

another optimization which also will simplify the handling of the
upcoming SH variant.

The functions fv_reg_base_num and dr_reg_base_num are basically
one-liner.  The expression they evaluate is fairly simple so
I'd suggest the following patch.  It converts both functions
into macros which will be evaluated inline.  This has the additional
advantage, that the functions in which they are called have access
to gdbarch, which comes in handy for the new SH variant.

If the conversion into macros is undesired, I'd like to suggest an
alternative implementation.  In that case I'd like to add gdbarch as
first parameter to both functions.


Thanks for considering,
Corinna


ChangeLog:

	* sh-tdep.c (FV_REG_BASE_NUM): New macro, substituting fv_reg_base_num.
	(DR_REG_BASE_NUM): New macro, substituting dr_reg_base_num.
	(fv_reg_base_num): Remove.
	(dr_reg_base_num): Remove.
	(sh_pseudo_register_read): Accomodate above change.
	(sh_pseudo_register_write): Ditto.
	(do_fv_register_info): Ditto.
	(do_dr_register_info): Ditto.

Index: sh-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/sh-tdep.c,v
retrieving revision 1.156
diff -u -p -r1.156 sh-tdep.c
--- sh-tdep.c	26 Jan 2004 20:52:12 -0000	1.156
+++ sh-tdep.c	11 Feb 2004 15:07:29 -0000
@@ -59,6 +59,11 @@ static void (*sh_show_regs) (void);
 
 #define SH_NUM_REGS 59
 
+/* For vectors of 4 floating point registers. */
+#define FV_REG_BASE_NUM(fv_reg) (FP0_REGNUM + ((fv_reg) - FV0_REGNUM) * 4)
+/* For double precision floating point registers, i.e 2 fp regs.*/
+#define DR_REG_BASE_NUM(dr_reg) (FP0_REGNUM + ((dr_reg) - DR0_REGNUM) * 2)
+
 struct sh_frame_cache
 {
   /* Base address.  */
@@ -1570,26 +1575,6 @@ sh_sh4_register_convert_to_raw (struct t
     error ("sh_register_convert_to_raw called with non DR register number");
 }
 
-/* For vectors of 4 floating point registers. */
-static int
-fv_reg_base_num (int fv_regnum)
-{
-  int fp_regnum;
-
-  fp_regnum = FP0_REGNUM + (fv_regnum - FV0_REGNUM) * 4;
-  return fp_regnum;
-}
-
-/* For double precision floating point registers, i.e 2 fp regs.*/
-static int
-dr_reg_base_num (int dr_regnum)
-{
-  int fp_regnum;
-
-  fp_regnum = FP0_REGNUM + (dr_regnum - DR0_REGNUM) * 2;
-  return fp_regnum;
-}
-
 static void
 sh_pseudo_register_read (struct gdbarch *gdbarch, struct regcache *regcache,
 			 int reg_nr, void *buffer)
@@ -1599,7 +1584,7 @@ sh_pseudo_register_read (struct gdbarch 
 
   if (reg_nr >= DR0_REGNUM && reg_nr <= DR_LAST_REGNUM)
     {
-      base_regnum = dr_reg_base_num (reg_nr);
+      base_regnum = DR_REG_BASE_NUM (reg_nr);
 
       /* Build the value in the provided buffer. */
       /* Read the real regs for which this one is an alias.  */
@@ -1616,7 +1601,7 @@ sh_pseudo_register_read (struct gdbarch 
     }
   else if (reg_nr >= FV0_REGNUM && reg_nr <= FV_LAST_REGNUM)
     {
-      base_regnum = fv_reg_base_num (reg_nr);
+      base_regnum = FV_REG_BASE_NUM (reg_nr);
 
       /* Read the real regs for which this one is an alias.  */
       for (portion = 0; portion < 4; portion++)
@@ -1636,7 +1621,7 @@ sh_pseudo_register_write (struct gdbarch
 
   if (reg_nr >= DR0_REGNUM && reg_nr <= DR_LAST_REGNUM)
     {
-      base_regnum = dr_reg_base_num (reg_nr);
+      base_regnum = DR_REG_BASE_NUM (reg_nr);
 
       /* We must pay attention to the endiannes. */
       sh_sh4_register_convert_to_raw (gdbarch_register_type (gdbarch, reg_nr),
@@ -1651,7 +1636,7 @@ sh_pseudo_register_write (struct gdbarch
     }
   else if (reg_nr >= FV0_REGNUM && reg_nr <= FV_LAST_REGNUM)
     {
-      base_regnum = fv_reg_base_num (reg_nr);
+      base_regnum = FV_REG_BASE_NUM (reg_nr);
 
       /* Write the real regs for which this one is an alias.  */
       for (portion = 0; portion < 4; portion++)
@@ -1667,7 +1652,7 @@ static void
 do_fv_register_info (struct gdbarch *gdbarch, struct ui_file *file,
 		     int fv_regnum)
 {
-  int first_fp_reg_num = fv_reg_base_num (fv_regnum);
+  int first_fp_reg_num = FV_REG_BASE_NUM (fv_regnum);
   fprintf_filtered (file, "fv%d\t0x%08x\t0x%08x\t0x%08x\t0x%08x\n",
 		    fv_regnum - FV0_REGNUM,
 		    (int) read_register (first_fp_reg_num),
@@ -1681,7 +1666,7 @@ static void
 do_dr_register_info (struct gdbarch *gdbarch, struct ui_file *file,
 		     int dr_regnum)
 {
-  int first_fp_reg_num = dr_reg_base_num (dr_regnum);
+  int first_fp_reg_num = DR_REG_BASE_NUM (dr_regnum);
 
   fprintf_filtered (file, "dr%d\t0x%08x%08x\n",
 		    dr_regnum - DR0_REGNUM,

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

Re: [RFA] sh-tdep.c: optimize fv_reg_base_num and dr_reg_base_num

[Elena Zannoni]

Corinna Vinschen writes:
 > Hi,
 > 
 > another optimization which also will simplify the handling of the
 > upcoming SH variant.
 > 
 > The functions fv_reg_base_num and dr_reg_base_num are basically
 > one-liner.  The expression they evaluate is fairly simple so
 > I'd suggest the following patch.  It converts both functions
 > into macros which will be evaluated inline.  This has the additional
 > advantage, that the functions in which they are called have access
 > to gdbarch, which comes in handy for the new SH variant.
 > 
 > If the conversion into macros is undesired, I'd like to suggest an
 > alternative implementation.  In that case I'd like to add gdbarch as
 > first parameter to both functions.

I prefer to not introduce macros here.  Can you explain where you are
headed? This looks like a micro optimization and I don't see the point
of it ATM.

Re: [RFA] sh-tdep.c: optimize fv_reg_base_num and dr_reg_base_num

[Corinna Vinschen]

On Feb 16 10:28, Elena Zannoni wrote:
> Corinna Vinschen writes:
>  > Hi,
>  > 
>  > another optimization which also will simplify the handling of the
>  > upcoming SH variant.
>  > 
>  > The functions fv_reg_base_num and dr_reg_base_num are basically
>  > one-liner.  The expression they evaluate is fairly simple so
>  > I'd suggest the following patch.  It converts both functions
>  > into macros which will be evaluated inline.  This has the additional
>  > advantage, that the functions in which they are called have access
>  > to gdbarch, which comes in handy for the new SH variant.
>  > 
>  > If the conversion into macros is undesired, I'd like to suggest an
>  > alternative implementation.  In that case I'd like to add gdbarch as
>  > first parameter to both functions.
> 
> I prefer to not introduce macros here.  Can you explain where you are
> headed? This looks like a micro optimization and I don't see the point
> of it ATM.

Gosh, I'm so sorry.  I should have cancled this RFA already days ago.
This is a result of the same thinko I talked about in my previous
mail.  The (blockheaded) idea was to use another SH_NUM_REGS for the
new CPU variant than for any other SH type.  I already scratched that
but I missed to note that here :-(

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

Re: [RFA] sh-tdep.c: optimize fv_reg_base_num and dr_reg_base_num

[Elena Zannoni]

Corinna Vinschen writes:
 > On Feb 16 10:28, Elena Zannoni wrote:
 > > Corinna Vinschen writes:
 > >  > Hi,
 > >  > 
 > >  > another optimization which also will simplify the handling of the
 > >  > upcoming SH variant.
 > >  > 
 > >  > The functions fv_reg_base_num and dr_reg_base_num are basically
 > >  > one-liner.  The expression they evaluate is fairly simple so
 > >  > I'd suggest the following patch.  It converts both functions
 > >  > into macros which will be evaluated inline.  This has the additional
 > >  > advantage, that the functions in which they are called have access
 > >  > to gdbarch, which comes in handy for the new SH variant.
 > >  > 
 > >  > If the conversion into macros is undesired, I'd like to suggest an
 > >  > alternative implementation.  In that case I'd like to add gdbarch as
 > >  > first parameter to both functions.
 > > 
 > > I prefer to not introduce macros here.  Can you explain where you are
 > > headed? This looks like a micro optimization and I don't see the point
 > > of it ATM.
 > 
 > Gosh, I'm so sorry.  I should have cancled this RFA already days ago.
 > This is a result of the same thinko I talked about in my previous
 > mail.  The (blockheaded) idea was to use another SH_NUM_REGS for the
 > new CPU variant than for any other SH type.  I already scratched that
 > but I missed to note that here :-(


Ok, I'll ignore this patch then.