new file mode 100644
@@ -0,0 +1,199 @@
+; Built-in functions for PowerPC.
+; Copyright (C) 2020-21 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.
+; For example, this could be
+;
+; [altivec]
+;
+; or it could be
+;
+; [power9]
+;
+; The bracketed gating predicate 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 double
+; long long
+; float
+; double
+; __int128
+; _Float128
+; bool
+; string
+; _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
+; v256 __vector_pair
+; v512 __vector_quad
+;
+; For simplicity, We don't support "short int" and "long long int".
+; We don't currently support a <basetype> of "_Float16". "signed"
+; and "unsigned" only apply to integral base types. The optional *
+; indicates a pointer type.
+;
+; 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
+; quad MMA instruction using a register quad as an input operand
+; pair MMA instruction using a register pair as an input operand
+; no32bit Not valid for TARGET_32BIT
+; 32bit Requires different handling for TARGET_32BIT
+; cpu This is a "cpu_is" or "cpu_supports" builtin
+; ldstmask Altivec mask for load or store
+; lxvrse Needs special handling for load-rightmost, sign-extended
+; lxvrze Needs special handling for load-rightmost, zero-extended
+; endian Needs special handling for endianness
+;
+; 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.
+;
+; The type signature for the builtin must match the modes of the RTL
+; pattern <bif-pattern>. When a builtin is used only as a basis for
+; overloading, you can use an arbitrary type for each mode (for example,
+; for V8HImode, you could use vp, vss, vus, or vbs). The overloading
+; machinery takes care of adding appropriate casts between vectors to
+; satisfy impedance matching. The overloaded prototypes are the ones
+; that must match what users expect. Thus you will often have a small
+; number of entries in this file that correspond to a much greater
+; number of entries in rs6000-overload.def.
+;
+; However, builtins in this file that are expected to be directly called
+; by users must have one version for each expected type combination.
+;
+; 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 {}
new file mode 100644
@@ -0,0 +1,82 @@
+; Overloaded built-in functions for PowerPC.
+; Copyright (C) 2020-21 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>[[, <ifdef>]] ]
+;
+; Here the single 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 rs6000-vecdefines.h;
+; <builtin-name> is the name that is overloaded in the back end; and
+; <ifdef> is an optional token used to guard the #define with an #ifdef
+; in rs6000-vecdefines.h. 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 this 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. It is
+; 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