From: Elena Zannoni <ezannoni@redhat.com>
To: gdb@sources.redhat.com
Subject: [RFC] Simplify SIMD registers
Date: Fri, 26 Apr 2002 19:35:00 -0000 [thread overview]
Message-ID: <15562.3668.39161.18708@localhost.redhat.com> (raw)
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);
next reply other threads:[~2002-04-27 2:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-26 19:35 Elena Zannoni [this message]
2002-04-27 23:06 ` Martin M. Hunt
2002-04-29 8:51 ` Elena Zannoni
2002-04-29 9:08 ` Elena Zannoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15562.3668.39161.18708@localhost.redhat.com \
--to=ezannoni@redhat.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox