public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
* [gcc(refs/users/wschmidt/heads/builtins4)] rs6000: Add initial input files
@ 2020-12-16 18:04 William Schmidt
  0 siblings, 0 replies; 4+ messages in thread
From: William Schmidt @ 2020-12-16 18:04 UTC (permalink / raw)
  To: gcc-cvs

https://gcc.gnu.org/g:13983cd85166229e4ca9b803c893dcfbf52d032e

commit 13983cd85166229e4ca9b803c893dcfbf52d032e
Author: Bill Schmidt <wschmidt@linux.ibm.com>
Date:   Fri Oct 30 17:39:23 2020 -0400

    rs6000: Add initial input files
    
    This patch adds a tiny subset of the built-in and overload descriptions.
    
    2020-10-30  Bill Schmidt  <wschmidt@linux.ibm.com>
    
            * config/rs6000/rs6000-builtin-new.def: New.
            * config/rs6000/rs6000-overload.def: New.

Diff:
---
 gcc/config/rs6000/rs6000-builtin-new.def | 194 +++++++++++++++++++++++++++++++
 gcc/config/rs6000/rs6000-overload.def    |  81 +++++++++++++
 2 files changed, 275 insertions(+)

diff --git a/gcc/config/rs6000/rs6000-builtin-new.def b/gcc/config/rs6000/rs6000-builtin-new.def
new file mode 100644
index 00000000000..385a0def647
--- /dev/null
+++ b/gcc/config/rs6000/rs6000-builtin-new.def
@@ -0,0 +1,194 @@
+; Built-in functions for PowerPC.
+; Copyright (C) 2020 Free Software Foundation, Inc.
+; Contributed by Bill Schmidt, IBM <wschmidt@linux.ibm.com>
+;
+; This file is part of GCC.
+;
+; GCC is free software; you can redistribute it and/or modify it under
+; the terms of the GNU General Public License as published by the Free
+; Software Foundation; either version 3, or (at your option) any later
+; version.
+;
+; GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+; WARRANTY; without even the implied warranty of MERCHANTABILITY or
+; FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+; for more details.
+;
+; You should have received a copy of the GNU General Public License
+; along with GCC; see the file COPYING3.  If not see
+; <http://www.gnu.org/licenses/>.
+
+
+; Built-in functions in this file are organized into "stanzas", where
+; all built-ins in a given stanza are enabled together.  Each stanza
+; starts with a line identifying the circumstances in which the group of
+; functions is permitted, with the gating predicate in square brackets.
+; This is the only information allowed on the stanza header line, other
+; than whitespace.
+;
+; Following the stanza header are two lines for each function: the
+; prototype line and the attributes line.  The prototype line has
+; this format, where the square brackets indicate optional
+; information and angle brackets indicate required information:
+;
+;   [kind] <return-type> <bif-name> (<argument-list>);
+;
+; Here [kind] can be one of "const", "pure", or "fpmath";
+; <return-type> is a legal type for a built-in function result;
+; <bif-name> is the name by which the function can be called;
+; and <argument-list> is a comma-separated list of legal types
+; for built-in function arguments.  The argument list may be
+; empty, but the parentheses and semicolon are required.
+;
+; A legal type is of the form:
+;
+;   [const] [[signed|unsigned] <basetype> | <vectype>] [*]
+;
+; where "const" applies only to a <basetype> of "int".  Legal values
+; of <basetype> are (for now):
+;
+;   char
+;   short
+;   int
+;   long long
+;   float
+;   double
+;   __int128
+;   _Float128
+;   _Decimal32
+;   _Decimal64
+;   _Decimal128
+;   __ibm128
+;
+; Legal values of <vectype> are as follows, and are shorthand for
+; the associated meaning:
+;
+;   vsc		vector signed char
+;   vuc		vector unsigned char
+;   vbc		vector bool char
+;   vss		vector signed short
+;   vus		vector unsigned short
+;   vbs		vector bool short
+;   vsi		vector signed int
+;   vui		vector unsigned int
+;   vbi		vector bool int
+;   vsll	vector signed long long
+;   vull	vector unsigned long long
+;   vbll	vector bool long long
+;   vsq		vector signed __int128
+;   vuq		vector unsigned __int128
+;   vbq		vector bool __int128
+;   vp		vector pixel
+;   vf		vector float
+;   vd		vector double
+;   vop		opaque vector (matches all vectors)
+;
+; For simplicity, We don't support "short int" and "long long int".
+; We don't currently support a <basetype> of "bool", "long double",
+; or "_Float16".  "signed" and "unsigned" only apply to integral base
+; types.  The optional * indicates a pointer type, which can be used
+; only with "void" and "const char" in this file.  (More specific
+; pointer types are allowed in overload prototypes.)
+;
+; The attributes line looks like this:
+;
+;   <bif-id> <bif-pattern> {<attribute-list>}
+;
+; Here <bif-id> is a unique internal identifier for the built-in
+; function that will be used as part of an enumeration of all
+; built-in functions; <bif-pattern> is the define_expand or
+; define_insn that will be invoked when the call is expanded;
+; and <attribute-list> is a comma-separated list of special
+; conditions that apply to the built-in function.  The attribute
+; list may be empty, but the braces are required.
+;
+; Attributes are strings, and the allowed ones are listed below.
+;
+;   init     Process as a vec_init function
+;   set      Process as a vec_set function
+;   extract  Process as a vec_extract function
+;   nosoft   Not valid with -msoft-float
+;   ldvec    Needs special handling for vec_ld semantics
+;   stvec    Needs special handling for vec_st semantics
+;   reve     Needs special handling for element reversal
+;   pred     Needs special handling for comparison predicates
+;   htm      Needs special handling for transactional memory
+;   htmspr   HTM function using an SPR
+;   htmcr    HTM function using a CR
+;   mma      Needs special handling for MMA
+;   no32bit  Not valid for TARGET_32BIT
+;   cpu      This is a "cpu_is" or "cpu_supports" builtin
+;   ldstmask Altivec mask for load or store
+;   lxvr     Needs special handling for load-rightmost
+;
+; Each attribute corresponds to extra processing required when
+; the built-in is expanded.  All such special processing should
+; be controlled by an attribute from now on.
+;
+; It is important to note that each entry's <bif-name> must be
+; unique.  The code generated from this file will call def_builtin
+; for each entry, and this can only happen once per name.  This
+; means that in some cases we currently retain some tricks from
+; the old builtin support to aid with overloading.  This 
+; unfortunately seems to be necessary for backward compatibility.
+;
+; The two tricks at our disposal are the void pointer and the "vop"
+; vector type.  We use void pointers anywhere that pointer types
+; are accepted (primarily for vector load/store built-ins).  In
+; practice this means that we accept pointers to anything, not
+; just to the types that we intend.  We use the "vop" vector type
+; anytime that a built-in must accept vector types that have
+; different modes.  This is an opaque type that will match any
+; vector type, which may mean matching vector types that we don't
+; intend.
+;
+; We can improve on "vop" when a vector argument or return type is
+; limited to one mode.  For example, "vsll" and "vull" both map to
+; V2DImode.  In this case, we can arbitrarily pick one of the
+; acceptable types to use in the prototype.  The signature used by
+; def_builtin is based on modes, not types, so this works well.
+; Only use "vop" when there is no alternative.  When there is a
+; choice, best practice is to use the signed type ("vsll" in the
+; example above) unless the choices are unsigned and bool, in
+; which case the unsigned type should be used.
+;
+; Eventually we want to automatically generate built-in documentation
+; from the entries in this file.  Documenting of built-ins with more
+; than one acceptable prototype can be done by cross-referencing
+; against rs6000-overload.def and picking up the allowable prototypes
+; from there.
+;
+; Blank lines may be used as desired in this file between the lines as
+; defined above; that is, you can introduce as many extra newlines as you
+; like after a required newline, but nowhere else.  Lines beginning with
+; a semicolon are also treated as blank lines.
+;
+; A const int argument may be restricted to certain values.  This is
+; indicated by one of the following occurring after the "int" token:
+;
+;    <x>   restricts the constant to x bits, interpreted as unsigned
+;    <x,y> restricts the constant to the inclusive range [x,y]
+;    [x,y] restricts the constant to the inclusive range [x,y],
+;	   but only applies if the argument is constant.
+;    {x,y} restricts the constant to one of two values, x or y.
+;
+; Here x and y are integer tokens.  Note that the "const" token is a
+; lie when the restriction is [x,y], but this simplifies the parsing
+; significantly and is hopefully forgivable.
+
+
+
+; AltiVec builtins.
+[altivec]
+  const vsc __builtin_altivec_abs_v16qi (vsc);
+    ABS_V16QI absv16qi2 {}
+
+  const vf __builtin_altivec_abs_v4sf (vf);
+    ABS_V4SF absv4sf2 {}
+
+  const vsi __builtin_altivec_abs_v4si (vsi);
+    ABS_V4SI absv4si2 {}
+
+  const vss __builtin_altivec_abs_v8hi (vss);
+    ABS_V8HI absv8hi2 {}
+
diff --git a/gcc/config/rs6000/rs6000-overload.def b/gcc/config/rs6000/rs6000-overload.def
new file mode 100644
index 00000000000..7c28cdcb84c
--- /dev/null
+++ b/gcc/config/rs6000/rs6000-overload.def
@@ -0,0 +1,81 @@
+; Overloaded built-in functions for PowerPC.
+; Copyright (C) 2020 Free Software Foundation, Inc.
+; Contributed by Bill Schmidt, IBM <wschmidt@linux.ibm.com>
+;
+; This file is part of GCC.
+;
+; GCC is free software; you can redistribute it and/or modify it under
+; the terms of the GNU General Public License as published by the Free
+; Software Foundation; either version 3, or (at your option) any later
+; version.
+;
+; GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+; WARRANTY; without even the implied warranty of MERCHANTABILITY or
+; FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+; for more details.
+;
+; You should have received a copy of the GNU General Public License
+; along with GCC; see the file COPYING3.  If not see
+; <http://www.gnu.org/licenses/>.
+
+
+; Overloaded built-in functions in this file are organized into "stanzas",
+; where all built-ins in a given stanza have the same overloaded function
+; name:
+;
+;   [<overload-id>, <abi-name>, <builtin-name>]
+;
+; Here the square brackets are part of the syntax, <overload-id> is a
+; unique internal identifier for the overload that will be used as part
+; of an enumeration of all overloaded functions; <abi-name> is the name
+; that will appear as a #define in altivec.h; and <builtin-name> is the
+; name that is overloaded in the back end.  If no #define is desired,
+; the <abi-name> should be replaced with the token SKIP.
+;
+; Each function entry has two lines.  The first line is a prototype line.
+; See rs6000-builtin-new.def for a description of the prototype line.
+; A prototype line in the file differs in that it doesn't have an
+; optional [kind] token:
+;
+;   <return-type> <internal-name> (<argument-list>);
+;
+; The second line contains the <bif-id> that this particular instance of
+; the overloaded function maps to.  It must match a token that appears in
+; rs6000-builtin-new.def.  Optionally, a second token may appear.  If only
+; one token is on the line, it is also used to build the unique identifier
+; for the overloaded function.  If a second token is present, the second
+; token is used instead for this purpose.  This is necessary in cases
+; where a built-in function accepts more than one type signature.  For
+; example, opaque vector types accept any vector type.  It is also common
+; to have a built-in function that, for example, specifies a "vector
+; signed char" argument, but accepts "vector unsigned char" and "vector
+; bool char" as well because only the mode matters.  Note that the
+; overload resolution mechanism has always handled these cases by
+; performing fold_convert on vector arguments to hide type mismatches,
+; and it will continue to do so.
+;
+; As a concrete example, __builtin_altivec_mtvscr uses an opaque argument
+; type for the source operand.  Its built-in function id is MTVSCR.  The
+; overloaded function __builtin_vec_mtvscr takes a variety of specific
+; types, but not all vector types.  Each of these maps to the same
+; __builtin_altivec_mtvscr built-in function, but the overload ID must
+; be unique, so we must specify the second token as shown here.
+;
+;[VEC_MTVSCR, vec_mtvscr, __builtin_vec_mtvscr]
+;  void __builtin_vec_mtvscr (vbc);
+;    MTVSCR  MTVSCR_VBC
+;  void __builtin_vec_mtvscr (vsc);
+;    MTVSCR  MTVSCR_VSC
+;  ...
+;
+; Blank lines may be used as desired in this file between the lines as
+; defined above; that is, you can introduce as many extra newlines as you
+; like after a required newline, but nowhere else.  Lines beginning with
+; a semicolon are also treated as blank lines.
+
+
+[VEC_ABS, vec_abs, __builtin_vec_abs]
+  vsc __builtin_vec_abs (vsc);
+    ABS_V16QI
+  vss __builtin_vec_abs (vss);
+    ABS_V8HI


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [gcc(refs/users/wschmidt/heads/builtins4)] rs6000: Add initial input files
@ 2021-02-07 18:11 William Schmidt
  0 siblings, 0 replies; 4+ messages in thread
From: William Schmidt @ 2021-02-07 18:11 UTC (permalink / raw)
  To: gcc-cvs

https://gcc.gnu.org/g:b0a07050b6f6976b0fd367e00cf353959ec5d086

commit b0a07050b6f6976b0fd367e00cf353959ec5d086
Author: Bill Schmidt <wschmidt@linux.ibm.com>
Date:   Fri Oct 30 17:39:23 2020 -0400

    rs6000: Add initial input files
    
    This patch adds a tiny subset of the built-in and overload descriptions.
    
    2020-10-30  Bill Schmidt  <wschmidt@linux.ibm.com>
    
            * config/rs6000/rs6000-builtin-new.def: New.
            * config/rs6000/rs6000-overload.def: New.

Diff:
---
 gcc/config/rs6000/rs6000-builtin-new.def | 194 +++++++++++++++++++++++++++++++
 gcc/config/rs6000/rs6000-overload.def    |  81 +++++++++++++
 2 files changed, 275 insertions(+)

diff --git a/gcc/config/rs6000/rs6000-builtin-new.def b/gcc/config/rs6000/rs6000-builtin-new.def
new file mode 100644
index 00000000000..385a0def647
--- /dev/null
+++ b/gcc/config/rs6000/rs6000-builtin-new.def
@@ -0,0 +1,194 @@
+; Built-in functions for PowerPC.
+; Copyright (C) 2020 Free Software Foundation, Inc.
+; Contributed by Bill Schmidt, IBM <wschmidt@linux.ibm.com>
+;
+; This file is part of GCC.
+;
+; GCC is free software; you can redistribute it and/or modify it under
+; the terms of the GNU General Public License as published by the Free
+; Software Foundation; either version 3, or (at your option) any later
+; version.
+;
+; GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+; WARRANTY; without even the implied warranty of MERCHANTABILITY or
+; FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+; for more details.
+;
+; You should have received a copy of the GNU General Public License
+; along with GCC; see the file COPYING3.  If not see
+; <http://www.gnu.org/licenses/>.
+
+
+; Built-in functions in this file are organized into "stanzas", where
+; all built-ins in a given stanza are enabled together.  Each stanza
+; starts with a line identifying the circumstances in which the group of
+; functions is permitted, with the gating predicate in square brackets.
+; This is the only information allowed on the stanza header line, other
+; than whitespace.
+;
+; Following the stanza header are two lines for each function: the
+; prototype line and the attributes line.  The prototype line has
+; this format, where the square brackets indicate optional
+; information and angle brackets indicate required information:
+;
+;   [kind] <return-type> <bif-name> (<argument-list>);
+;
+; Here [kind] can be one of "const", "pure", or "fpmath";
+; <return-type> is a legal type for a built-in function result;
+; <bif-name> is the name by which the function can be called;
+; and <argument-list> is a comma-separated list of legal types
+; for built-in function arguments.  The argument list may be
+; empty, but the parentheses and semicolon are required.
+;
+; A legal type is of the form:
+;
+;   [const] [[signed|unsigned] <basetype> | <vectype>] [*]
+;
+; where "const" applies only to a <basetype> of "int".  Legal values
+; of <basetype> are (for now):
+;
+;   char
+;   short
+;   int
+;   long long
+;   float
+;   double
+;   __int128
+;   _Float128
+;   _Decimal32
+;   _Decimal64
+;   _Decimal128
+;   __ibm128
+;
+; Legal values of <vectype> are as follows, and are shorthand for
+; the associated meaning:
+;
+;   vsc		vector signed char
+;   vuc		vector unsigned char
+;   vbc		vector bool char
+;   vss		vector signed short
+;   vus		vector unsigned short
+;   vbs		vector bool short
+;   vsi		vector signed int
+;   vui		vector unsigned int
+;   vbi		vector bool int
+;   vsll	vector signed long long
+;   vull	vector unsigned long long
+;   vbll	vector bool long long
+;   vsq		vector signed __int128
+;   vuq		vector unsigned __int128
+;   vbq		vector bool __int128
+;   vp		vector pixel
+;   vf		vector float
+;   vd		vector double
+;   vop		opaque vector (matches all vectors)
+;
+; For simplicity, We don't support "short int" and "long long int".
+; We don't currently support a <basetype> of "bool", "long double",
+; or "_Float16".  "signed" and "unsigned" only apply to integral base
+; types.  The optional * indicates a pointer type, which can be used
+; only with "void" and "const char" in this file.  (More specific
+; pointer types are allowed in overload prototypes.)
+;
+; The attributes line looks like this:
+;
+;   <bif-id> <bif-pattern> {<attribute-list>}
+;
+; Here <bif-id> is a unique internal identifier for the built-in
+; function that will be used as part of an enumeration of all
+; built-in functions; <bif-pattern> is the define_expand or
+; define_insn that will be invoked when the call is expanded;
+; and <attribute-list> is a comma-separated list of special
+; conditions that apply to the built-in function.  The attribute
+; list may be empty, but the braces are required.
+;
+; Attributes are strings, and the allowed ones are listed below.
+;
+;   init     Process as a vec_init function
+;   set      Process as a vec_set function
+;   extract  Process as a vec_extract function
+;   nosoft   Not valid with -msoft-float
+;   ldvec    Needs special handling for vec_ld semantics
+;   stvec    Needs special handling for vec_st semantics
+;   reve     Needs special handling for element reversal
+;   pred     Needs special handling for comparison predicates
+;   htm      Needs special handling for transactional memory
+;   htmspr   HTM function using an SPR
+;   htmcr    HTM function using a CR
+;   mma      Needs special handling for MMA
+;   no32bit  Not valid for TARGET_32BIT
+;   cpu      This is a "cpu_is" or "cpu_supports" builtin
+;   ldstmask Altivec mask for load or store
+;   lxvr     Needs special handling for load-rightmost
+;
+; Each attribute corresponds to extra processing required when
+; the built-in is expanded.  All such special processing should
+; be controlled by an attribute from now on.
+;
+; It is important to note that each entry's <bif-name> must be
+; unique.  The code generated from this file will call def_builtin
+; for each entry, and this can only happen once per name.  This
+; means that in some cases we currently retain some tricks from
+; the old builtin support to aid with overloading.  This 
+; unfortunately seems to be necessary for backward compatibility.
+;
+; The two tricks at our disposal are the void pointer and the "vop"
+; vector type.  We use void pointers anywhere that pointer types
+; are accepted (primarily for vector load/store built-ins).  In
+; practice this means that we accept pointers to anything, not
+; just to the types that we intend.  We use the "vop" vector type
+; anytime that a built-in must accept vector types that have
+; different modes.  This is an opaque type that will match any
+; vector type, which may mean matching vector types that we don't
+; intend.
+;
+; We can improve on "vop" when a vector argument or return type is
+; limited to one mode.  For example, "vsll" and "vull" both map to
+; V2DImode.  In this case, we can arbitrarily pick one of the
+; acceptable types to use in the prototype.  The signature used by
+; def_builtin is based on modes, not types, so this works well.
+; Only use "vop" when there is no alternative.  When there is a
+; choice, best practice is to use the signed type ("vsll" in the
+; example above) unless the choices are unsigned and bool, in
+; which case the unsigned type should be used.
+;
+; Eventually we want to automatically generate built-in documentation
+; from the entries in this file.  Documenting of built-ins with more
+; than one acceptable prototype can be done by cross-referencing
+; against rs6000-overload.def and picking up the allowable prototypes
+; from there.
+;
+; Blank lines may be used as desired in this file between the lines as
+; defined above; that is, you can introduce as many extra newlines as you
+; like after a required newline, but nowhere else.  Lines beginning with
+; a semicolon are also treated as blank lines.
+;
+; A const int argument may be restricted to certain values.  This is
+; indicated by one of the following occurring after the "int" token:
+;
+;    <x>   restricts the constant to x bits, interpreted as unsigned
+;    <x,y> restricts the constant to the inclusive range [x,y]
+;    [x,y] restricts the constant to the inclusive range [x,y],
+;	   but only applies if the argument is constant.
+;    {x,y} restricts the constant to one of two values, x or y.
+;
+; Here x and y are integer tokens.  Note that the "const" token is a
+; lie when the restriction is [x,y], but this simplifies the parsing
+; significantly and is hopefully forgivable.
+
+
+
+; AltiVec builtins.
+[altivec]
+  const vsc __builtin_altivec_abs_v16qi (vsc);
+    ABS_V16QI absv16qi2 {}
+
+  const vf __builtin_altivec_abs_v4sf (vf);
+    ABS_V4SF absv4sf2 {}
+
+  const vsi __builtin_altivec_abs_v4si (vsi);
+    ABS_V4SI absv4si2 {}
+
+  const vss __builtin_altivec_abs_v8hi (vss);
+    ABS_V8HI absv8hi2 {}
+
diff --git a/gcc/config/rs6000/rs6000-overload.def b/gcc/config/rs6000/rs6000-overload.def
new file mode 100644
index 00000000000..7c28cdcb84c
--- /dev/null
+++ b/gcc/config/rs6000/rs6000-overload.def
@@ -0,0 +1,81 @@
+; Overloaded built-in functions for PowerPC.
+; Copyright (C) 2020 Free Software Foundation, Inc.
+; Contributed by Bill Schmidt, IBM <wschmidt@linux.ibm.com>
+;
+; This file is part of GCC.
+;
+; GCC is free software; you can redistribute it and/or modify it under
+; the terms of the GNU General Public License as published by the Free
+; Software Foundation; either version 3, or (at your option) any later
+; version.
+;
+; GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+; WARRANTY; without even the implied warranty of MERCHANTABILITY or
+; FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+; for more details.
+;
+; You should have received a copy of the GNU General Public License
+; along with GCC; see the file COPYING3.  If not see
+; <http://www.gnu.org/licenses/>.
+
+
+; Overloaded built-in functions in this file are organized into "stanzas",
+; where all built-ins in a given stanza have the same overloaded function
+; name:
+;
+;   [<overload-id>, <abi-name>, <builtin-name>]
+;
+; Here the square brackets are part of the syntax, <overload-id> is a
+; unique internal identifier for the overload that will be used as part
+; of an enumeration of all overloaded functions; <abi-name> is the name
+; that will appear as a #define in altivec.h; and <builtin-name> is the
+; name that is overloaded in the back end.  If no #define is desired,
+; the <abi-name> should be replaced with the token SKIP.
+;
+; Each function entry has two lines.  The first line is a prototype line.
+; See rs6000-builtin-new.def for a description of the prototype line.
+; A prototype line in the file differs in that it doesn't have an
+; optional [kind] token:
+;
+;   <return-type> <internal-name> (<argument-list>);
+;
+; The second line contains the <bif-id> that this particular instance of
+; the overloaded function maps to.  It must match a token that appears in
+; rs6000-builtin-new.def.  Optionally, a second token may appear.  If only
+; one token is on the line, it is also used to build the unique identifier
+; for the overloaded function.  If a second token is present, the second
+; token is used instead for this purpose.  This is necessary in cases
+; where a built-in function accepts more than one type signature.  For
+; example, opaque vector types accept any vector type.  It is also common
+; to have a built-in function that, for example, specifies a "vector
+; signed char" argument, but accepts "vector unsigned char" and "vector
+; bool char" as well because only the mode matters.  Note that the
+; overload resolution mechanism has always handled these cases by
+; performing fold_convert on vector arguments to hide type mismatches,
+; and it will continue to do so.
+;
+; As a concrete example, __builtin_altivec_mtvscr uses an opaque argument
+; type for the source operand.  Its built-in function id is MTVSCR.  The
+; overloaded function __builtin_vec_mtvscr takes a variety of specific
+; types, but not all vector types.  Each of these maps to the same
+; __builtin_altivec_mtvscr built-in function, but the overload ID must
+; be unique, so we must specify the second token as shown here.
+;
+;[VEC_MTVSCR, vec_mtvscr, __builtin_vec_mtvscr]
+;  void __builtin_vec_mtvscr (vbc);
+;    MTVSCR  MTVSCR_VBC
+;  void __builtin_vec_mtvscr (vsc);
+;    MTVSCR  MTVSCR_VSC
+;  ...
+;
+; Blank lines may be used as desired in this file between the lines as
+; defined above; that is, you can introduce as many extra newlines as you
+; like after a required newline, but nowhere else.  Lines beginning with
+; a semicolon are also treated as blank lines.
+
+
+[VEC_ABS, vec_abs, __builtin_vec_abs]
+  vsc __builtin_vec_abs (vsc);
+    ABS_V16QI
+  vss __builtin_vec_abs (vss);
+    ABS_V8HI


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [gcc(refs/users/wschmidt/heads/builtins4)] rs6000: Add initial input files
@ 2020-11-24 16:42 William Schmidt
  0 siblings, 0 replies; 4+ messages in thread
From: William Schmidt @ 2020-11-24 16:42 UTC (permalink / raw)
  To: gcc-cvs

https://gcc.gnu.org/g:6765600acb56685f1d81c2ad30a7b71b84cfe2d0

commit 6765600acb56685f1d81c2ad30a7b71b84cfe2d0
Author: Bill Schmidt <wschmidt@linux.ibm.com>
Date:   Fri Oct 30 17:39:23 2020 -0400

    rs6000: Add initial input files
    
    This patch adds a tiny subset of the built-in and overload descriptions.
    
    2020-10-30  Bill Schmidt  <wschmidt@linux.ibm.com>
    
            * config/rs6000/rs6000-builtin-new.def: New.
            * config/rs6000/rs6000-overload.def: New.

Diff:
---
 gcc/config/rs6000/rs6000-builtin-new.def | 194 +++++++++++++++++++++++++++++++
 gcc/config/rs6000/rs6000-overload.def    |  81 +++++++++++++
 2 files changed, 275 insertions(+)

diff --git a/gcc/config/rs6000/rs6000-builtin-new.def b/gcc/config/rs6000/rs6000-builtin-new.def
new file mode 100644
index 00000000000..385a0def647
--- /dev/null
+++ b/gcc/config/rs6000/rs6000-builtin-new.def
@@ -0,0 +1,194 @@
+; Built-in functions for PowerPC.
+; Copyright (C) 2020 Free Software Foundation, Inc.
+; Contributed by Bill Schmidt, IBM <wschmidt@linux.ibm.com>
+;
+; This file is part of GCC.
+;
+; GCC is free software; you can redistribute it and/or modify it under
+; the terms of the GNU General Public License as published by the Free
+; Software Foundation; either version 3, or (at your option) any later
+; version.
+;
+; GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+; WARRANTY; without even the implied warranty of MERCHANTABILITY or
+; FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+; for more details.
+;
+; You should have received a copy of the GNU General Public License
+; along with GCC; see the file COPYING3.  If not see
+; <http://www.gnu.org/licenses/>.
+
+
+; Built-in functions in this file are organized into "stanzas", where
+; all built-ins in a given stanza are enabled together.  Each stanza
+; starts with a line identifying the circumstances in which the group of
+; functions is permitted, with the gating predicate in square brackets.
+; This is the only information allowed on the stanza header line, other
+; than whitespace.
+;
+; Following the stanza header are two lines for each function: the
+; prototype line and the attributes line.  The prototype line has
+; this format, where the square brackets indicate optional
+; information and angle brackets indicate required information:
+;
+;   [kind] <return-type> <bif-name> (<argument-list>);
+;
+; Here [kind] can be one of "const", "pure", or "fpmath";
+; <return-type> is a legal type for a built-in function result;
+; <bif-name> is the name by which the function can be called;
+; and <argument-list> is a comma-separated list of legal types
+; for built-in function arguments.  The argument list may be
+; empty, but the parentheses and semicolon are required.
+;
+; A legal type is of the form:
+;
+;   [const] [[signed|unsigned] <basetype> | <vectype>] [*]
+;
+; where "const" applies only to a <basetype> of "int".  Legal values
+; of <basetype> are (for now):
+;
+;   char
+;   short
+;   int
+;   long long
+;   float
+;   double
+;   __int128
+;   _Float128
+;   _Decimal32
+;   _Decimal64
+;   _Decimal128
+;   __ibm128
+;
+; Legal values of <vectype> are as follows, and are shorthand for
+; the associated meaning:
+;
+;   vsc		vector signed char
+;   vuc		vector unsigned char
+;   vbc		vector bool char
+;   vss		vector signed short
+;   vus		vector unsigned short
+;   vbs		vector bool short
+;   vsi		vector signed int
+;   vui		vector unsigned int
+;   vbi		vector bool int
+;   vsll	vector signed long long
+;   vull	vector unsigned long long
+;   vbll	vector bool long long
+;   vsq		vector signed __int128
+;   vuq		vector unsigned __int128
+;   vbq		vector bool __int128
+;   vp		vector pixel
+;   vf		vector float
+;   vd		vector double
+;   vop		opaque vector (matches all vectors)
+;
+; For simplicity, We don't support "short int" and "long long int".
+; We don't currently support a <basetype> of "bool", "long double",
+; or "_Float16".  "signed" and "unsigned" only apply to integral base
+; types.  The optional * indicates a pointer type, which can be used
+; only with "void" and "const char" in this file.  (More specific
+; pointer types are allowed in overload prototypes.)
+;
+; The attributes line looks like this:
+;
+;   <bif-id> <bif-pattern> {<attribute-list>}
+;
+; Here <bif-id> is a unique internal identifier for the built-in
+; function that will be used as part of an enumeration of all
+; built-in functions; <bif-pattern> is the define_expand or
+; define_insn that will be invoked when the call is expanded;
+; and <attribute-list> is a comma-separated list of special
+; conditions that apply to the built-in function.  The attribute
+; list may be empty, but the braces are required.
+;
+; Attributes are strings, and the allowed ones are listed below.
+;
+;   init     Process as a vec_init function
+;   set      Process as a vec_set function
+;   extract  Process as a vec_extract function
+;   nosoft   Not valid with -msoft-float
+;   ldvec    Needs special handling for vec_ld semantics
+;   stvec    Needs special handling for vec_st semantics
+;   reve     Needs special handling for element reversal
+;   pred     Needs special handling for comparison predicates
+;   htm      Needs special handling for transactional memory
+;   htmspr   HTM function using an SPR
+;   htmcr    HTM function using a CR
+;   mma      Needs special handling for MMA
+;   no32bit  Not valid for TARGET_32BIT
+;   cpu      This is a "cpu_is" or "cpu_supports" builtin
+;   ldstmask Altivec mask for load or store
+;   lxvr     Needs special handling for load-rightmost
+;
+; Each attribute corresponds to extra processing required when
+; the built-in is expanded.  All such special processing should
+; be controlled by an attribute from now on.
+;
+; It is important to note that each entry's <bif-name> must be
+; unique.  The code generated from this file will call def_builtin
+; for each entry, and this can only happen once per name.  This
+; means that in some cases we currently retain some tricks from
+; the old builtin support to aid with overloading.  This 
+; unfortunately seems to be necessary for backward compatibility.
+;
+; The two tricks at our disposal are the void pointer and the "vop"
+; vector type.  We use void pointers anywhere that pointer types
+; are accepted (primarily for vector load/store built-ins).  In
+; practice this means that we accept pointers to anything, not
+; just to the types that we intend.  We use the "vop" vector type
+; anytime that a built-in must accept vector types that have
+; different modes.  This is an opaque type that will match any
+; vector type, which may mean matching vector types that we don't
+; intend.
+;
+; We can improve on "vop" when a vector argument or return type is
+; limited to one mode.  For example, "vsll" and "vull" both map to
+; V2DImode.  In this case, we can arbitrarily pick one of the
+; acceptable types to use in the prototype.  The signature used by
+; def_builtin is based on modes, not types, so this works well.
+; Only use "vop" when there is no alternative.  When there is a
+; choice, best practice is to use the signed type ("vsll" in the
+; example above) unless the choices are unsigned and bool, in
+; which case the unsigned type should be used.
+;
+; Eventually we want to automatically generate built-in documentation
+; from the entries in this file.  Documenting of built-ins with more
+; than one acceptable prototype can be done by cross-referencing
+; against rs6000-overload.def and picking up the allowable prototypes
+; from there.
+;
+; Blank lines may be used as desired in this file between the lines as
+; defined above; that is, you can introduce as many extra newlines as you
+; like after a required newline, but nowhere else.  Lines beginning with
+; a semicolon are also treated as blank lines.
+;
+; A const int argument may be restricted to certain values.  This is
+; indicated by one of the following occurring after the "int" token:
+;
+;    <x>   restricts the constant to x bits, interpreted as unsigned
+;    <x,y> restricts the constant to the inclusive range [x,y]
+;    [x,y] restricts the constant to the inclusive range [x,y],
+;	   but only applies if the argument is constant.
+;    {x,y} restricts the constant to one of two values, x or y.
+;
+; Here x and y are integer tokens.  Note that the "const" token is a
+; lie when the restriction is [x,y], but this simplifies the parsing
+; significantly and is hopefully forgivable.
+
+
+
+; AltiVec builtins.
+[altivec]
+  const vsc __builtin_altivec_abs_v16qi (vsc);
+    ABS_V16QI absv16qi2 {}
+
+  const vf __builtin_altivec_abs_v4sf (vf);
+    ABS_V4SF absv4sf2 {}
+
+  const vsi __builtin_altivec_abs_v4si (vsi);
+    ABS_V4SI absv4si2 {}
+
+  const vss __builtin_altivec_abs_v8hi (vss);
+    ABS_V8HI absv8hi2 {}
+
diff --git a/gcc/config/rs6000/rs6000-overload.def b/gcc/config/rs6000/rs6000-overload.def
new file mode 100644
index 00000000000..7c28cdcb84c
--- /dev/null
+++ b/gcc/config/rs6000/rs6000-overload.def
@@ -0,0 +1,81 @@
+; Overloaded built-in functions for PowerPC.
+; Copyright (C) 2020 Free Software Foundation, Inc.
+; Contributed by Bill Schmidt, IBM <wschmidt@linux.ibm.com>
+;
+; This file is part of GCC.
+;
+; GCC is free software; you can redistribute it and/or modify it under
+; the terms of the GNU General Public License as published by the Free
+; Software Foundation; either version 3, or (at your option) any later
+; version.
+;
+; GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+; WARRANTY; without even the implied warranty of MERCHANTABILITY or
+; FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+; for more details.
+;
+; You should have received a copy of the GNU General Public License
+; along with GCC; see the file COPYING3.  If not see
+; <http://www.gnu.org/licenses/>.
+
+
+; Overloaded built-in functions in this file are organized into "stanzas",
+; where all built-ins in a given stanza have the same overloaded function
+; name:
+;
+;   [<overload-id>, <abi-name>, <builtin-name>]
+;
+; Here the square brackets are part of the syntax, <overload-id> is a
+; unique internal identifier for the overload that will be used as part
+; of an enumeration of all overloaded functions; <abi-name> is the name
+; that will appear as a #define in altivec.h; and <builtin-name> is the
+; name that is overloaded in the back end.  If no #define is desired,
+; the <abi-name> should be replaced with the token SKIP.
+;
+; Each function entry has two lines.  The first line is a prototype line.
+; See rs6000-builtin-new.def for a description of the prototype line.
+; A prototype line in the file differs in that it doesn't have an
+; optional [kind] token:
+;
+;   <return-type> <internal-name> (<argument-list>);
+;
+; The second line contains the <bif-id> that this particular instance of
+; the overloaded function maps to.  It must match a token that appears in
+; rs6000-builtin-new.def.  Optionally, a second token may appear.  If only
+; one token is on the line, it is also used to build the unique identifier
+; for the overloaded function.  If a second token is present, the second
+; token is used instead for this purpose.  This is necessary in cases
+; where a built-in function accepts more than one type signature.  For
+; example, opaque vector types accept any vector type.  It is also common
+; to have a built-in function that, for example, specifies a "vector
+; signed char" argument, but accepts "vector unsigned char" and "vector
+; bool char" as well because only the mode matters.  Note that the
+; overload resolution mechanism has always handled these cases by
+; performing fold_convert on vector arguments to hide type mismatches,
+; and it will continue to do so.
+;
+; As a concrete example, __builtin_altivec_mtvscr uses an opaque argument
+; type for the source operand.  Its built-in function id is MTVSCR.  The
+; overloaded function __builtin_vec_mtvscr takes a variety of specific
+; types, but not all vector types.  Each of these maps to the same
+; __builtin_altivec_mtvscr built-in function, but the overload ID must
+; be unique, so we must specify the second token as shown here.
+;
+;[VEC_MTVSCR, vec_mtvscr, __builtin_vec_mtvscr]
+;  void __builtin_vec_mtvscr (vbc);
+;    MTVSCR  MTVSCR_VBC
+;  void __builtin_vec_mtvscr (vsc);
+;    MTVSCR  MTVSCR_VSC
+;  ...
+;
+; Blank lines may be used as desired in this file between the lines as
+; defined above; that is, you can introduce as many extra newlines as you
+; like after a required newline, but nowhere else.  Lines beginning with
+; a semicolon are also treated as blank lines.
+
+
+[VEC_ABS, vec_abs, __builtin_vec_abs]
+  vsc __builtin_vec_abs (vsc);
+    ABS_V16QI
+  vss __builtin_vec_abs (vss);
+    ABS_V8HI


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [gcc(refs/users/wschmidt/heads/builtins4)] rs6000: Add initial input files
@ 2020-10-30 21:39 William Schmidt
  0 siblings, 0 replies; 4+ messages in thread
From: William Schmidt @ 2020-10-30 21:39 UTC (permalink / raw)
  To: gcc-cvs

https://gcc.gnu.org/g:469f4e1bdf77e432d8ea436ae3b2f17829f652ec

commit 469f4e1bdf77e432d8ea436ae3b2f17829f652ec
Author: Bill Schmidt <wschmidt@linux.ibm.com>
Date:   Fri Oct 30 17:39:23 2020 -0400

    rs6000: Add initial input files
    
    This patch adds a tiny subset of the built-in and overload descriptions.
    
    2020-10-30  Bill Schmidt  <wschmidt@linux.ibm.com>
    
            * config/rs6000/rs6000-builtin-new.def: New.
            * config/rs6000/rs6000-overload.def: New.

Diff:
---
 gcc/config/rs6000/rs6000-builtin-new.def | 194 +++++++++++++++++++++++++++++++
 gcc/config/rs6000/rs6000-overload.def    |  81 +++++++++++++
 2 files changed, 275 insertions(+)

diff --git a/gcc/config/rs6000/rs6000-builtin-new.def b/gcc/config/rs6000/rs6000-builtin-new.def
new file mode 100644
index 00000000000..385a0def647
--- /dev/null
+++ b/gcc/config/rs6000/rs6000-builtin-new.def
@@ -0,0 +1,194 @@
+; Built-in functions for PowerPC.
+; Copyright (C) 2020 Free Software Foundation, Inc.
+; Contributed by Bill Schmidt, IBM <wschmidt@linux.ibm.com>
+;
+; This file is part of GCC.
+;
+; GCC is free software; you can redistribute it and/or modify it under
+; the terms of the GNU General Public License as published by the Free
+; Software Foundation; either version 3, or (at your option) any later
+; version.
+;
+; GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+; WARRANTY; without even the implied warranty of MERCHANTABILITY or
+; FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+; for more details.
+;
+; You should have received a copy of the GNU General Public License
+; along with GCC; see the file COPYING3.  If not see
+; <http://www.gnu.org/licenses/>.
+
+
+; Built-in functions in this file are organized into "stanzas", where
+; all built-ins in a given stanza are enabled together.  Each stanza
+; starts with a line identifying the circumstances in which the group of
+; functions is permitted, with the gating predicate in square brackets.
+; This is the only information allowed on the stanza header line, other
+; than whitespace.
+;
+; Following the stanza header are two lines for each function: the
+; prototype line and the attributes line.  The prototype line has
+; this format, where the square brackets indicate optional
+; information and angle brackets indicate required information:
+;
+;   [kind] <return-type> <bif-name> (<argument-list>);
+;
+; Here [kind] can be one of "const", "pure", or "fpmath";
+; <return-type> is a legal type for a built-in function result;
+; <bif-name> is the name by which the function can be called;
+; and <argument-list> is a comma-separated list of legal types
+; for built-in function arguments.  The argument list may be
+; empty, but the parentheses and semicolon are required.
+;
+; A legal type is of the form:
+;
+;   [const] [[signed|unsigned] <basetype> | <vectype>] [*]
+;
+; where "const" applies only to a <basetype> of "int".  Legal values
+; of <basetype> are (for now):
+;
+;   char
+;   short
+;   int
+;   long long
+;   float
+;   double
+;   __int128
+;   _Float128
+;   _Decimal32
+;   _Decimal64
+;   _Decimal128
+;   __ibm128
+;
+; Legal values of <vectype> are as follows, and are shorthand for
+; the associated meaning:
+;
+;   vsc		vector signed char
+;   vuc		vector unsigned char
+;   vbc		vector bool char
+;   vss		vector signed short
+;   vus		vector unsigned short
+;   vbs		vector bool short
+;   vsi		vector signed int
+;   vui		vector unsigned int
+;   vbi		vector bool int
+;   vsll	vector signed long long
+;   vull	vector unsigned long long
+;   vbll	vector bool long long
+;   vsq		vector signed __int128
+;   vuq		vector unsigned __int128
+;   vbq		vector bool __int128
+;   vp		vector pixel
+;   vf		vector float
+;   vd		vector double
+;   vop		opaque vector (matches all vectors)
+;
+; For simplicity, We don't support "short int" and "long long int".
+; We don't currently support a <basetype> of "bool", "long double",
+; or "_Float16".  "signed" and "unsigned" only apply to integral base
+; types.  The optional * indicates a pointer type, which can be used
+; only with "void" and "const char" in this file.  (More specific
+; pointer types are allowed in overload prototypes.)
+;
+; The attributes line looks like this:
+;
+;   <bif-id> <bif-pattern> {<attribute-list>}
+;
+; Here <bif-id> is a unique internal identifier for the built-in
+; function that will be used as part of an enumeration of all
+; built-in functions; <bif-pattern> is the define_expand or
+; define_insn that will be invoked when the call is expanded;
+; and <attribute-list> is a comma-separated list of special
+; conditions that apply to the built-in function.  The attribute
+; list may be empty, but the braces are required.
+;
+; Attributes are strings, and the allowed ones are listed below.
+;
+;   init     Process as a vec_init function
+;   set      Process as a vec_set function
+;   extract  Process as a vec_extract function
+;   nosoft   Not valid with -msoft-float
+;   ldvec    Needs special handling for vec_ld semantics
+;   stvec    Needs special handling for vec_st semantics
+;   reve     Needs special handling for element reversal
+;   pred     Needs special handling for comparison predicates
+;   htm      Needs special handling for transactional memory
+;   htmspr   HTM function using an SPR
+;   htmcr    HTM function using a CR
+;   mma      Needs special handling for MMA
+;   no32bit  Not valid for TARGET_32BIT
+;   cpu      This is a "cpu_is" or "cpu_supports" builtin
+;   ldstmask Altivec mask for load or store
+;   lxvr     Needs special handling for load-rightmost
+;
+; Each attribute corresponds to extra processing required when
+; the built-in is expanded.  All such special processing should
+; be controlled by an attribute from now on.
+;
+; It is important to note that each entry's <bif-name> must be
+; unique.  The code generated from this file will call def_builtin
+; for each entry, and this can only happen once per name.  This
+; means that in some cases we currently retain some tricks from
+; the old builtin support to aid with overloading.  This 
+; unfortunately seems to be necessary for backward compatibility.
+;
+; The two tricks at our disposal are the void pointer and the "vop"
+; vector type.  We use void pointers anywhere that pointer types
+; are accepted (primarily for vector load/store built-ins).  In
+; practice this means that we accept pointers to anything, not
+; just to the types that we intend.  We use the "vop" vector type
+; anytime that a built-in must accept vector types that have
+; different modes.  This is an opaque type that will match any
+; vector type, which may mean matching vector types that we don't
+; intend.
+;
+; We can improve on "vop" when a vector argument or return type is
+; limited to one mode.  For example, "vsll" and "vull" both map to
+; V2DImode.  In this case, we can arbitrarily pick one of the
+; acceptable types to use in the prototype.  The signature used by
+; def_builtin is based on modes, not types, so this works well.
+; Only use "vop" when there is no alternative.  When there is a
+; choice, best practice is to use the signed type ("vsll" in the
+; example above) unless the choices are unsigned and bool, in
+; which case the unsigned type should be used.
+;
+; Eventually we want to automatically generate built-in documentation
+; from the entries in this file.  Documenting of built-ins with more
+; than one acceptable prototype can be done by cross-referencing
+; against rs6000-overload.def and picking up the allowable prototypes
+; from there.
+;
+; Blank lines may be used as desired in this file between the lines as
+; defined above; that is, you can introduce as many extra newlines as you
+; like after a required newline, but nowhere else.  Lines beginning with
+; a semicolon are also treated as blank lines.
+;
+; A const int argument may be restricted to certain values.  This is
+; indicated by one of the following occurring after the "int" token:
+;
+;    <x>   restricts the constant to x bits, interpreted as unsigned
+;    <x,y> restricts the constant to the inclusive range [x,y]
+;    [x,y] restricts the constant to the inclusive range [x,y],
+;	   but only applies if the argument is constant.
+;    {x,y} restricts the constant to one of two values, x or y.
+;
+; Here x and y are integer tokens.  Note that the "const" token is a
+; lie when the restriction is [x,y], but this simplifies the parsing
+; significantly and is hopefully forgivable.
+
+
+
+; AltiVec builtins.
+[altivec]
+  const vsc __builtin_altivec_abs_v16qi (vsc);
+    ABS_V16QI absv16qi2 {}
+
+  const vf __builtin_altivec_abs_v4sf (vf);
+    ABS_V4SF absv4sf2 {}
+
+  const vsi __builtin_altivec_abs_v4si (vsi);
+    ABS_V4SI absv4si2 {}
+
+  const vss __builtin_altivec_abs_v8hi (vss);
+    ABS_V8HI absv8hi2 {}
+
diff --git a/gcc/config/rs6000/rs6000-overload.def b/gcc/config/rs6000/rs6000-overload.def
new file mode 100644
index 00000000000..7c28cdcb84c
--- /dev/null
+++ b/gcc/config/rs6000/rs6000-overload.def
@@ -0,0 +1,81 @@
+; Overloaded built-in functions for PowerPC.
+; Copyright (C) 2020 Free Software Foundation, Inc.
+; Contributed by Bill Schmidt, IBM <wschmidt@linux.ibm.com>
+;
+; This file is part of GCC.
+;
+; GCC is free software; you can redistribute it and/or modify it under
+; the terms of the GNU General Public License as published by the Free
+; Software Foundation; either version 3, or (at your option) any later
+; version.
+;
+; GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+; WARRANTY; without even the implied warranty of MERCHANTABILITY or
+; FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+; for more details.
+;
+; You should have received a copy of the GNU General Public License
+; along with GCC; see the file COPYING3.  If not see
+; <http://www.gnu.org/licenses/>.
+
+
+; Overloaded built-in functions in this file are organized into "stanzas",
+; where all built-ins in a given stanza have the same overloaded function
+; name:
+;
+;   [<overload-id>, <abi-name>, <builtin-name>]
+;
+; Here the square brackets are part of the syntax, <overload-id> is a
+; unique internal identifier for the overload that will be used as part
+; of an enumeration of all overloaded functions; <abi-name> is the name
+; that will appear as a #define in altivec.h; and <builtin-name> is the
+; name that is overloaded in the back end.  If no #define is desired,
+; the <abi-name> should be replaced with the token SKIP.
+;
+; Each function entry has two lines.  The first line is a prototype line.
+; See rs6000-builtin-new.def for a description of the prototype line.
+; A prototype line in the file differs in that it doesn't have an
+; optional [kind] token:
+;
+;   <return-type> <internal-name> (<argument-list>);
+;
+; The second line contains the <bif-id> that this particular instance of
+; the overloaded function maps to.  It must match a token that appears in
+; rs6000-builtin-new.def.  Optionally, a second token may appear.  If only
+; one token is on the line, it is also used to build the unique identifier
+; for the overloaded function.  If a second token is present, the second
+; token is used instead for this purpose.  This is necessary in cases
+; where a built-in function accepts more than one type signature.  For
+; example, opaque vector types accept any vector type.  It is also common
+; to have a built-in function that, for example, specifies a "vector
+; signed char" argument, but accepts "vector unsigned char" and "vector
+; bool char" as well because only the mode matters.  Note that the
+; overload resolution mechanism has always handled these cases by
+; performing fold_convert on vector arguments to hide type mismatches,
+; and it will continue to do so.
+;
+; As a concrete example, __builtin_altivec_mtvscr uses an opaque argument
+; type for the source operand.  Its built-in function id is MTVSCR.  The
+; overloaded function __builtin_vec_mtvscr takes a variety of specific
+; types, but not all vector types.  Each of these maps to the same
+; __builtin_altivec_mtvscr built-in function, but the overload ID must
+; be unique, so we must specify the second token as shown here.
+;
+;[VEC_MTVSCR, vec_mtvscr, __builtin_vec_mtvscr]
+;  void __builtin_vec_mtvscr (vbc);
+;    MTVSCR  MTVSCR_VBC
+;  void __builtin_vec_mtvscr (vsc);
+;    MTVSCR  MTVSCR_VSC
+;  ...
+;
+; Blank lines may be used as desired in this file between the lines as
+; defined above; that is, you can introduce as many extra newlines as you
+; like after a required newline, but nowhere else.  Lines beginning with
+; a semicolon are also treated as blank lines.
+
+
+[VEC_ABS, vec_abs, __builtin_vec_abs]
+  vsc __builtin_vec_abs (vsc);
+    ABS_V16QI
+  vss __builtin_vec_abs (vss);
+    ABS_V8HI


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-02-07 18:11 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-16 18:04 [gcc(refs/users/wschmidt/heads/builtins4)] rs6000: Add initial input files William Schmidt
  -- strict thread matches above, loose matches on Subject: below --
2021-02-07 18:11 William Schmidt
2020-11-24 16:42 William Schmidt
2020-10-30 21:39 William Schmidt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).