From: Segher Boessenkool <segher@kernel.crashing.org>
To: Bill Schmidt <wschmidt@linux.ibm.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH 01/14] Initial create of rs6000-genbif.c.
Date: Tue, 04 Feb 2020 18:27:00 -0000 [thread overview]
Message-ID: <20200204182732.GL22482@gate.crashing.org> (raw)
In-Reply-To: <02715c0fbae6d6c4332c6effe939acc9c0df9a4d.1580782131.git.wschmidt@linux.ibm.com>
Hi!
On Mon, Feb 03, 2020 at 08:26:02PM -0600, Bill Schmidt wrote:
> Includes header documentation and initial set of include directives.
Please use full sentences in commit messages.
> +/* This program generates built-in function initialization and
> + recognition code for Power targets, based on text files that
> + describe the built-in functions and vector overloads:
> +
> + rs6000-bif.def Table of built-in functions
> + rs6000-overload.def Table of overload functions
I really don't think using the new acronym "bif" helps; built-in
functions already are often called "builtins" (or "intrinsics", which is
problematic itself).
> + ext Process as a vec_extract function
Please spell out "extract"? There are too many other words starting with
"ext", some of which you could expect here ("extend", "extension", maybe
even "extra");
> + ldv Needs special handling for vec_ld semantics
> + stv Needs special handling for vec_st semantics
Call those "vec_ld" and "vec_st", then? Or should I get used to it, the
names aren't obvious, but cut-and-paste always is ;-)
> +[TARGET_ALTIVEC]
Can this be a C expression? Most gen* programs just copy similar things
to the generated C code, which can be interesting to debug, but works
perfectly well otherwise.
> + const vector signed char __builtin_altivec_abs_v16qi (vector signed char);
> + ABS_V16QI absv16qi2 {abs}
> + const vector signed short __builtin_altivec_abs_v8hi (vector signed short);
> + ABS_V8HI absv8hi2 {abs}
> +
> + Note the use of indentation, which is recommended but not required.
It does require a single newline at the end of each such line, right?
Does that work aout almost always, or do you get very long lines?
> + [<overload-id>, <external-name>, <internal-name>]
Hrm, "internal" suggests "name within the GCC code", but that is not what
it means. Maybe something like abi-name and builtin-name?
> + Blank lines may be used as desired in these files.
Between stanzas and stuff only? There are places where newlines are
significant and not just whitespace, right?
Great docs, thanks!
Segher
next prev parent reply other threads:[~2020-02-04 18:27 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-04 2:26 [PATCH 00/14] rs6000: Begin replacing built-in support Bill Schmidt
2020-02-04 2:26 ` [PATCH 02/14] Add stubs for input files. These will grow much larger Bill Schmidt
2020-02-04 2:26 ` [PATCH 01/14] Initial create of rs6000-genbif.c Bill Schmidt
2020-02-04 18:27 ` Segher Boessenkool [this message]
2020-02-04 21:10 ` Bill Schmidt
2020-02-04 22:36 ` Segher Boessenkool
2020-02-04 22:44 ` Bill Schmidt
2020-02-04 23:48 ` Segher Boessenkool
2020-02-04 2:27 ` [PATCH 05/14] Add support functions for matching types Bill Schmidt
2020-02-04 2:27 ` [PATCH 14/14] Incorporate new code into the build machinery Bill Schmidt
2020-02-04 2:27 ` [PATCH 09/14] Add parsing support for rs6000-overload.def Bill Schmidt
2020-02-04 2:27 ` [PATCH 03/14] Add file support and functions for diagnostic support Bill Schmidt
2020-02-04 2:27 ` [PATCH 08/14] Add support for parsing rs6000-bif.def Bill Schmidt
2020-02-04 2:27 ` [PATCH 06/14] Red-black tree implementation for balanced tree search Bill Schmidt
2020-02-04 2:27 ` [PATCH 07/14] Add main function with stub functions for parsing and output Bill Schmidt
2020-02-04 2:27 ` [PATCH 12/14] Write code to rs6000-bif.h Bill Schmidt
2020-02-04 2:27 ` [PATCH 04/14] Support functions to parse whitespace, lines, identifiers, integers Bill Schmidt
2020-02-04 2:27 ` [PATCH 11/14] Write #defines to rs6000-vecdefines.h Bill Schmidt
2020-02-04 2:27 ` [PATCH 10/14] Build function type identifiers and store them Bill Schmidt
2020-02-04 2:27 ` [PATCH 13/14] Write code to rs6000-bif.c Bill Schmidt
2020-02-04 17:40 ` [PATCH 00/14] rs6000: Begin replacing built-in support Segher Boessenkool
2020-02-05 7:57 ` Richard Biener
2020-02-05 12:30 ` Segher Boessenkool
2020-02-05 13:01 ` Bill Schmidt
2020-02-14 18:34 ` Mike Stump
2020-02-14 21:27 ` Segher Boessenkool
2020-02-15 0:14 ` Mike Stump
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=20200204182732.GL22482@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=wschmidt@linux.ibm.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).