[RFC] Updating PowerPC's overload vector table

[RFC] Updating PowerPC's overload vector table

[Michael Meissner]

As I beging work on extensions for a potential future machine, I am running
into the overload table.  In the power7 timeframe, I just gritted my teeth, and
added all of the appropriate entries, but I would like to visit making the
table somewhat friendlier to edit and add new overloaded functions.
Unfortunately in its current state, the table makes it easy to forget some
entries, and people's eyes glaze over it when making lots of changes.

To recapp the current situation, rs6000-c.c defines a table that given an
overloaded builtin, it will return an insn that does the builtin for the
particular argument types defined.

struct altivec_builtin_types
{
  enum rs6000_builtins code;
  enum rs6000_builtins overloaded_code;
  signed char ret_type;
  signed char op1;
  signed char op2;
  signed char op3;
};


Here are all of the entries just for __builtin_vec_add:

const struct altivec_builtin_types altivec_overloaded_builtins[] = {
	/* ... */
  /* Binary AltiVec/VSX builtins.  */
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUBM,
    RS6000_BTI_V16QI, RS6000_BTI_bool_V16QI, RS6000_BTI_V16QI, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUBM,
    RS6000_BTI_V16QI, RS6000_BTI_V16QI, RS6000_BTI_bool_V16QI, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUBM,
    RS6000_BTI_V16QI, RS6000_BTI_V16QI, RS6000_BTI_V16QI, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUBM,
    RS6000_BTI_unsigned_V16QI, RS6000_BTI_bool_V16QI, RS6000_BTI_unsigned_V16QI, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUBM,
    RS6000_BTI_unsigned_V16QI, RS6000_BTI_unsigned_V16QI, RS6000_BTI_bool_V16QI, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUBM,
    RS6000_BTI_unsigned_V16QI, RS6000_BTI_unsigned_V16QI, RS6000_BTI_unsigned_V16QI, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUHM,
    RS6000_BTI_V8HI, RS6000_BTI_bool_V8HI, RS6000_BTI_V8HI, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUHM,
    RS6000_BTI_V8HI, RS6000_BTI_V8HI, RS6000_BTI_bool_V8HI, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUHM,
    RS6000_BTI_V8HI, RS6000_BTI_V8HI, RS6000_BTI_V8HI, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUHM,
    RS6000_BTI_unsigned_V8HI, RS6000_BTI_bool_V8HI, RS6000_BTI_unsigned_V8HI, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUHM,
    RS6000_BTI_unsigned_V8HI, RS6000_BTI_unsigned_V8HI, RS6000_BTI_bool_V8HI, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUHM,
    RS6000_BTI_unsigned_V8HI, RS6000_BTI_unsigned_V8HI, RS6000_BTI_unsigned_V8HI, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUWM,
    RS6000_BTI_V4SI, RS6000_BTI_bool_V4SI, RS6000_BTI_V4SI, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUWM,
    RS6000_BTI_V4SI, RS6000_BTI_V4SI, RS6000_BTI_bool_V4SI, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUWM,
    RS6000_BTI_V4SI, RS6000_BTI_V4SI, RS6000_BTI_V4SI, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUWM,
    RS6000_BTI_unsigned_V4SI, RS6000_BTI_bool_V4SI, RS6000_BTI_unsigned_V4SI, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUWM,
    RS6000_BTI_unsigned_V4SI, RS6000_BTI_unsigned_V4SI, RS6000_BTI_bool_V4SI, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUWM,
    RS6000_BTI_unsigned_V4SI, RS6000_BTI_unsigned_V4SI, RS6000_BTI_unsigned_V4SI, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUDM,
    RS6000_BTI_V2DI, RS6000_BTI_bool_V2DI, RS6000_BTI_V2DI, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUDM,
    RS6000_BTI_V2DI, RS6000_BTI_V2DI, RS6000_BTI_bool_V2DI, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUDM,
    RS6000_BTI_V2DI, RS6000_BTI_V2DI, RS6000_BTI_V2DI, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUDM,
    RS6000_BTI_unsigned_V2DI, RS6000_BTI_bool_V2DI, RS6000_BTI_unsigned_V2DI, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUDM,
    RS6000_BTI_unsigned_V2DI, RS6000_BTI_unsigned_V2DI, RS6000_BTI_bool_V2DI, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUDM,
    RS6000_BTI_unsigned_V2DI, RS6000_BTI_unsigned_V2DI, RS6000_BTI_unsigned_V2DI, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDFP,
    RS6000_BTI_V4SF, RS6000_BTI_V4SF, RS6000_BTI_V4SF, 0 },
  { ALTIVEC_BUILTIN_VEC_ADD, VSX_BUILTIN_XVADDDP,
    RS6000_BTI_V2DF, RS6000_BTI_V2DF, RS6000_BTI_V2DF, 0 },
	/* ... */
};

and this is repeated over and over again for each function.  I would like to
propose something like

/* Signed builtins with vectors that take 2 arguments.  Allow bool vector of
   the same type as one of the arguments.  */
#define BU_SIGN_2(OVERLOAD, INSTANCE, TYPE)				\
  { OVERLOAD, INSTANCE, RS6000_BTI_ ## TYPE, RS6000_BTI_ ## TYPE,	\
    RS6000_BTI_ ## TYPE, 0 },						\
  { OVERLOAD, INSTANCE, RS6000_BTI_ ## TYPE, RS6000_BTI_ ## TYPE,	\
    RS6000_BTI_bool_ ## TYPE, 0 },					\
  { OVERLOAD, INSTANCE, RS6000_BTI_ ## TYPE, RS6000_BTI_bool_ ## TYPE,	\
    RS6000_BTI_ ## TYPE, 0 }

/* Unsigned builtins with vectors that take 2 arguments.  Allow bool vector of
   the same type as one of the arguments.  */
#define BU_UNS_2(OVERLOAD, INSTANCE, TYPE)				\
  { OVERLOAD, INSTANCE, RS6000_BTI_unsigned_ ## TYPE,			\
    RS6000_BTI_unsigned ## TYPE, RS6000_BTI_unsigned_ ## TYPE, 0 },	\
  { OVERLOAD, INSTANCE, RS6000_BTI_unsigned_ ## TYPE,			\
    RS6000_BTI_bool ## TYPE, RS6000_BTI_unsigned_ ## TYPE, 0 },	\
  { OVERLOAD, INSTANCE, RS6000_BTI_unsigned_ ## TYPE,			\
    RS6000_BTI_unsigned ## TYPE, RS6000_BTI_bool_ ## TYPE, 0 }

/* Both signed and unsigned builtins.  */
#define BU_BOTH_2(OVERLOAD, INSTANCE, TYPE)				\
  AV_BU_SIGN_2(OVERLOAD, INSTANCE, TYPE),				\
  AV_BU_UNS_2(OVERLOAD, INSTANCE, TYPE)

/* Floating point builtins that take 2 arguments of the same type.  */
#define BU_FP_2(OVERLOAD, INSTANCE, TYPE)				\
  { OVERLOAD, INSTANCE, RS6000_BTI_ ## TYPE, RS6000_BTI_ ## TYPE,	\
    RS6000_BTI_ ## TYPE, 0 },

const struct altivec_builtin_types altivec_overloaded_builtins[] = {
	/* ... */
  /* Binary AltiVec/VSX builtins.  */
  BU_BOTH_2 (ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUBM, V16QI),
  BU_BOTH_2 (ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUHM, V8HI),
  BU_BOTH_2 (ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDUWM, V4SI),
  BU_FP_2   (ALTIVEC_BUILTIN_VEC_ADD, ALTIVEC_BUILTIN_VADDFP,  V4SF),
  BU_FP_2   (ALTIVEC_BUILTIN_VEC_ADD, VSX_BUILTIN_XVADDDP,     V2DF)
};

Doing this I could do piecemeal, for example doing just the above lines for one
submission, since the reworking of the macros generates exactly the same
representation, but it is easier to read (IMHO).  Shifts and min/max for
instance would use separate signed/unsigned macros, rather than using the both
macros.

Now, it bothers me that every time we do the overloaded builtins, we
essentially have to scan the table in a linear fashion.  I'm thinking that we
may want to move these tables into separate arrays, one for each overloaded
function, with a null marker at the end.  This is more of a radical reworking.
If I did this, I likely would keep the big table as a last resort, and add the
arrays, one at a time.

Any thoughts?

-- 
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meissner@linux.vnet.ibm.com	fax +1 (978) 399-6899

Re: [RFC] Updating PowerPC's overload vector table

[Segher Boessenkool]

> const struct altivec_builtin_types altivec_overloaded_builtins[] = {

[big fat table constructed using many macros]

> Now, it bothers me that every time we do the overloaded builtins, we
> essentially have to scan the table in a linear fashion.  I'm  
> thinking that we
> may want to move these tables into separate arrays, one for each  
> overloaded
> function, with a null marker at the end.  This is more of a radical  
> reworking.
> If I did this, I likely would keep the big table as a last resort,  
> and add the
> arrays, one at a time.
>
> Any thoughts?

You could construct the table at runtime, using helper functions for
the regular groups.  It's easy to make a more efficient data structure
as well then.


Segher

Re: [RFC] Updating PowerPC's overload vector table

[Mike Stump]

On Oct 19, 2012, at 2:27 PM, Michael Meissner <meissner@linux.vnet.ibm.com> wrote:
> As I beging work on extensions for a potential future machine, I am running
> into the overload table.

I still like the built-in mechanism Kenny and I have....  Not perfect, but vastly better...  If you wanted to help submitify it....  I bet we could fine a way to get it to you.  Iterators, overloading, over load resolution, in parameters, in/out parameters, ties nicely into RL patterns.  .md specification language for them, a generator so one only has a specification; the implementation it generated by the generator.  Doesn't yet generate documentation, but that is 20 lines away if I had to guess.