[RFC] Simplify SIMD registers

[RFC] Simplify SIMD registers

[Elena Zannoni]

Now that we have a TYPE_VECTOR attribute that identifies an array as a
vector, I think it is possible to simplify the representation of SIMD
registers by dropping the structure wrapping around each element of
the union.

At present the registers are represented like this:

(gdb) info reg vr2
vr2            {uint128 = 0x006f00de014d01bc022b029a03090378, v4sf = {f = {
      0x0, 0x0, 0x0, 0x0}}, v4si = {f = {0x6f00de, 0x14d01bc, 0x22b029a, 
      0x3090378}}, v8hi = {f = {0x6f, 0xde, 0x14d, 0x1bc, 0x22b, 0x29a, 0x309, 
      0x378}}, v16qi = {f = {0x0, 0x6f, 0x0, 0xde, 0x1, 0x4d, 0x1, 0xbc, 0x2, 
      0x2b, 0x2, 0x9a, 0x3, 0x9, 0x3, 0x78}}}
(gdb) ptype $vr2
type = union __gdb_builtin_type_vec128 {
    int128_t uint128;
    struct __builtin_v4sf v4sf;
    struct __builtin_v4si v4si;
    struct __builtin_v8hi v8hi;
    struct __builtin_v16qi v16qi;
}
(gdb) ptype $vr2.v4sf
type = struct __builtin_v4sf {
    float f[4];
}

While a single variable is like this:

(gdb) ptype vshort_f
type = short int [8]


With the proposed simplification a SIMD register would look like:


(gdb) info reg vr2
vr2            {uint128 = 0x00000000000000000000000000000000, av4sf = {0x0, 
    0x0, 0x0, 0x0}, av4si = {0x0, 0x0, 0x0, 0x0}, av8hi = {0x0, 0x0, 0x0, 0x0, 
    0x0, 0x0, 0x0, 0x0}, av16qi = {0x0 <repeats 16 times>}}

(gdb) p $vr2.av4sf[0]
$1 = 0
(gdb) set $vr2.av4sf = {1,1,1,1}

(gdb) ptype $vr2
type = union __gdb_builtin_type_vec128 {
    int128_t uint128;
    float av4sf[4];
    int32_t av4si[4];
    int16_t av8hi[8];
    int8_t av16qi[16];
}


Now, I have concerns for platforms other than Altivec, that may have
used a representation like the one I would like to abandon.
I am talking about SSE regs on x86 which are v4sf type. Right?

For this reason I didn't touch the existing built in types which have
the structure wrapping, but I introduced new ones to be used by
AltiVec registers.

Comments? 

I don't like the choice of names. But I cannot think of decent
ones. The 'a' I added is for 'array', but that is a bit silly.

I didn't change __builtin_type_vec128 to __builtin_type_avec128, since
Altivec is the only one using this type and can cope with the change.

Elena

(Will submit a proper patch later)


Index: gdbtypes.c
===================================================================
RCS file: /cvs/uberbaum/gdb/gdbtypes.c,v
retrieving revision 1.44
diff -u -p -r1.44 gdbtypes.c
--- gdbtypes.c	26 Apr 2002 20:08:18 -0000	1.44
+++ gdbtypes.c	27 Apr 2002 02:27:51 -0000
@@ -71,6 +71,13 @@ struct type *builtin_type_uint64;
 struct type *builtin_type_int128;
 struct type *builtin_type_uint128;
 struct type *builtin_type_bool;
+struct type *builtin_type_av4sf;
+struct type *builtin_type_av4si;
+struct type *builtin_type_av16qi;
+struct type *builtin_type_av8qi;
+struct type *builtin_type_av8hi;
+struct type *builtin_type_av4hi;
+struct type *builtin_type_av2si;
 struct type *builtin_type_v4sf;
 struct type *builtin_type_v4si;
 struct type *builtin_type_v16qi;
@@ -804,6 +811,18 @@ init_simd_type (char *name,
 }
 
 static struct type *
+init_simda_type (struct type *elt_type, int n)
+{
+  struct type *array_type;
+ 
+  array_type = create_array_type (0, elt_type,
+			create_range_type (0, builtin_type_int,
+			0, n-1));
+  TYPE_FLAGS (array_type) |= TYPE_FLAG_VECTOR;
+  return array_type;
+}
+
+static struct type *
 build_builtin_type_vec128 (void)
 {
   /* Construct a type for the 128 bit registers.  The type we're
@@ -817,16 +836,25 @@ build_builtin_type_vec128 (void)
     struct __builtin_v4sf v4sf;
     uint128_t uint128;
   };
+
+ union __gdb_builtin_type_vec128 
+  {
+    int128_t uint128;
+    float av4sf[4];
+    int32_t av4si[4];
+    int16_t av8hi[8];
+    int8_t av16qi[16];
+  };
 #endif
 
   struct type *t;
 
   t = init_composite_type ("__gdb_builtin_type_vec128", TYPE_CODE_UNION);
   append_composite_type_field (t, "uint128", builtin_type_int128);
-  append_composite_type_field (t, "v4sf", builtin_type_v4sf);
-  append_composite_type_field (t, "v4si", builtin_type_v4si);
-  append_composite_type_field (t, "v8hi", builtin_type_v8hi);
-  append_composite_type_field (t, "v16qi", builtin_type_v16qi);
+  append_composite_type_field (t, "av4sf", builtin_type_av4sf);
+  append_composite_type_field (t, "av4si", builtin_type_av4si);
+  append_composite_type_field (t, "av8hi", builtin_type_av8hi);
+  append_composite_type_field (t, "av16qi", builtin_type_av16qi);
 
   return t;
 }
@@ -3282,6 +3310,21 @@ build_gdbtypes (void)
   builtin_type_v2si
     = init_simd_type ("__builtin_v2si", builtin_type_int32, "f", 2);
 
+  builtin_type_av4sf
+    = init_simda_type (builtin_type_float, 4);
+  builtin_type_av4si
+    = init_simda_type (builtin_type_int32, 4);
+  builtin_type_av16qi
+    = init_simda_type (builtin_type_int8, 16);
+  builtin_type_av8qi
+    = init_simda_type (builtin_type_int8, 8);
+  builtin_type_av8hi
+    = init_simda_type (builtin_type_int16, 8);
+  builtin_type_av4hi
+    = init_simda_type (builtin_type_int16, 4);
+  builtin_type_av2si
+    = init_simda_type (builtin_type_int32, 2);
+
   /* Vector types. */
   builtin_type_vec128
     = build_builtin_type_vec128 ();
@@ -3373,6 +3416,13 @@ _initialize_gdbtypes (void)
   register_gdbarch_swap (&builtin_type_v8hi, sizeof (struct type *), NULL);
   register_gdbarch_swap (&builtin_type_v4hi, sizeof (struct type *), NULL);
   register_gdbarch_swap (&builtin_type_v2si, sizeof (struct type *), NULL);
+  register_gdbarch_swap (&builtin_type_av4sf, sizeof (struct type *), NULL);
+  register_gdbarch_swap (&builtin_type_av4si, sizeof (struct type *), NULL);
+  register_gdbarch_swap (&builtin_type_av16qi, sizeof (struct type *), NULL);
+  register_gdbarch_swap (&builtin_type_av8qi, sizeof (struct type *), NULL);
+  register_gdbarch_swap (&builtin_type_av8hi, sizeof (struct type *), NULL);
+  register_gdbarch_swap (&builtin_type_av4hi, sizeof (struct type *), NULL);
+  register_gdbarch_swap (&builtin_type_av2si, sizeof (struct type *), NULL);
   register_gdbarch_swap (&builtin_type_vec128, sizeof (struct type *), NULL);
   REGISTER_GDBARCH_SWAP (builtin_type_void_data_ptr);
   REGISTER_GDBARCH_SWAP (builtin_type_void_func_ptr);

Re: [RFC] Simplify SIMD registers

[Martin M. Hunt]

On Fri, 26 Apr 2002, Elena Zannoni wrote:

> Now, I have concerns for platforms other than Altivec, that may have
> used a representation like the one I would like to abandon.
> I am talking about SSE regs on x86 which are v4sf type. Right?

SSE registers are v4sf only, but SSE2 registers (Pentium 4) are
v2df, v4sf, v16qi, v8hi, v4si, and v2di. I don't believe GDB supports 
them yet.


> For this reason I didn't touch the existing built in types which have
> the structure wrapping, but I introduced new ones to be used by
> AltiVec registers.
> 
> Comments? 

I would like to see us treat all SIMD registers in the same manner, not 
just Altivec. Even though the packing and size will vary, the display 
syntax should be consistent.

Martin

Re: [RFC] Simplify SIMD registers

[Elena Zannoni]

Martin M. Hunt writes:
 > On Fri, 26 Apr 2002, Elena Zannoni wrote:
 > 
 > > Now, I have concerns for platforms other than Altivec, that may have
 > > used a representation like the one I would like to abandon.
 > > I am talking about SSE regs on x86 which are v4sf type. Right?
 > 
 > SSE registers are v4sf only, but SSE2 registers (Pentium 4) are
 > v2df, v4sf, v16qi, v8hi, v4si, and v2di. I don't believe GDB supports 
 > them yet.
 > 

Ah ok, so those could be supported w/o structure wrappers. But the
debug format is only stabs on x86, and we don't set the flags for those
types to TYPE_VECTOR. If we did that we could avoid the structures.

 > 
 > > For this reason I didn't touch the existing built in types which have
 > > the structure wrapping, but I introduced new ones to be used by
 > > AltiVec registers.
 > > 
 > > Comments? 
 > 
 > I would like to see us treat all SIMD registers in the same manner, not 
 > just Altivec. Even though the packing and size will vary, the display 
 > syntax should be consistent.
 > 

Yes, I would like this too. 
Any opinions from the x86 aficionados? Eli? Daniel? Mark?

 > Martin

Elena

Re: [RFC] Simplify SIMD registers

[Elena Zannoni]

Elena Zannoni writes:
 > Martin M. Hunt writes:
 >  > On Fri, 26 Apr 2002, Elena Zannoni wrote:
 >  > 
 >  > > Now, I have concerns for platforms other than Altivec, that may have
 >  > > used a representation like the one I would like to abandon.
 >  > > I am talking about SSE regs on x86 which are v4sf type. Right?
 >  > 
 >  > SSE registers are v4sf only, but SSE2 registers (Pentium 4) are
 >  > v2df, v4sf, v16qi, v8hi, v4si, and v2di. I don't believe GDB supports 
 >  > them yet.
 >  > 
 > 
 > Ah ok, so those could be supported w/o structure wrappers. But the
 > debug format is only stabs on x86, and we don't set the flags for those
 > types to TYPE_VECTOR. If we did that we could avoid the structures.
 > 

No sorry, what I just said is nonsense, we can always set the
TYPE_VECTOR flags for the register types because it is set by gdb
itself.  Do these vectors on x86 appear also as variables? I mean,
would there be a function that takes a vector as parameter, for
instance? (In that case we would need to deal with stabs debug info).

Elena