[01/14] Initial create of rs6000-genbif.c.

Message ID 02715c0fbae6d6c4332c6effe939acc9c0df9a4d.1580782131.git.wschmidt@linux.ibm.com
State New
Headers show
Series
  • rs6000: Begin replacing built-in support
Related show

Commit Message

Bill Schmidt Feb. 4, 2020, 2:26 a.m.
Includes header documentation and initial set of include directives.

2020-02-03  Bill Schmidt  <wschmidt@linux.ibm.com>

        * config/rs6000/rs6000-genbif.c: New file.
---
 gcc/config/rs6000/rs6000-genbif.c | 124 ++++++++++++++++++++++++++++++
 1 file changed, 124 insertions(+)
 create mode 100644 gcc/config/rs6000/rs6000-genbif.c

-- 
2.17.1

Comments

Segher Boessenkool Feb. 4, 2020, 6:27 p.m. | #1
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
Bill Schmidt Feb. 4, 2020, 9:10 p.m. | #2
On 2/4/20 12:27 PM, Segher Boessenkool wrote:
> 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.



OK.

>

>> +/* 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).



Until we manage to replace the old methods, we already have 
rs6000-builtin.def, so I am a bit constrained in my choices. Given that 
restriction, what name would you prefer?  I can use rs6000-builtins.def 
(the plural) if you like.

I didn't think I was inventing "bif" as shorthand, but maybe that was an 
LLVM thing...

>

>> +     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");



OK.

>

>> +     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 ;-)



Hm.  Well, vec_ld is a specific built-in, but this applies to a few more 
than just that one.  But sure, if you want.

>

>> +[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.



I rather prefer the way it is.  I do generate C code from this in the 
subsequent patches.  But I like table-driven code to use things that 
look like tables for input. :-)

>

>> +  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?



Yes, for now I am requiring the newline at the end of each line. I found 
that it does indeed get very long (unreadably long) lines for vector 
signatures.  I forgot to update this documentation when I changed my 
format.  I am now using abbreviations for vector types that match those 
we use often in our test cases ("vuc" for "vector unsigned char", "vsll" 
for "vector signed long long", etc.).  This makes for very nicely 
readable inputs (see patch #2).

The above now becomes

   const vsc __builtin_altivec_abs_v16qi (vsc);
     ABS_V16QI absv16qi2 {abs}
   const vss __builtin_altivec_abs_v8hi (vss);
     ABS_V8HI absv8hi2 {abs}

I will fix the documentation!

>

>> +     [<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?



OK, that's reasonable.

>

>> +  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?



I don't believe so, although there may be places where I forgot to allow 
a line to be advanced -- that would be a bug, though, so let me know if 
you see any.  Blank lines don't have any inherent meaning in the input 
files.

>

> Great docs, thanks!



Thanks for the review!
Bill

>

>

> Segher
Segher Boessenkool Feb. 4, 2020, 10:36 p.m. | #3
On Tue, Feb 04, 2020 at 03:10:32PM -0600, Bill Schmidt wrote:
> >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).

> 

> Until we manage to replace the old methods, we already have 

> rs6000-builtin.def, so I am a bit constrained in my choices. Given that 

> restriction, what name would you prefer?  I can use rs6000-builtins.def 

> (the plural) if you like.


As we discussed (offline), maybe rs6000-builtin-new.def is best (and at
the end of this conversion, just move it).

> >>+     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 ;-)

> 

> Hm.  Well, vec_ld is a specific built-in, but this applies to a few more 

> than just that one.  But sure, if you want.


"ldv" certainly is shorter and nicer in principle, but it is a bit
cryptic.  As I said, it's probably not too hard to get used to it; and
maybe a better name will present itself?

> >>+[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.

> 

> I rather prefer the way it is.  I do generate C code from this in the 

> subsequent patches.  But I like table-driven code to use things that 

> look like tables for input. :-)


That's not what I meant...  Can you say
  [TARGET_ALTIVEC && TARGET_64BIT]
here?  Or even just
  [!TARGET_ALTIVEC]
or
  [1]
for always, or
  [0]
for never ("commented out").

> >>+  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?

> 

> I don't believe so, although there may be places where I forgot to allow 

> a line to be advanced -- that would be a bug, though, so let me know if 

> you see any.  Blank lines don't have any inherent meaning in the input 

> files.


Not blank lines, I'm asking about newlines :-)  But those are not allowed
to be inserted just anywhere, a line has to be one line, iiuc?


Segher
Bill Schmidt Feb. 4, 2020, 10:44 p.m. | #4
On 2/4/20 4:36 PM, Segher Boessenkool wrote:
> On Tue, Feb 04, 2020 at 03:10:32PM -0600, Bill Schmidt wrote:

>>> 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).

>> Until we manage to replace the old methods, we already have

>> rs6000-builtin.def, so I am a bit constrained in my choices. Given that

>> restriction, what name would you prefer?  I can use rs6000-builtins.def

>> (the plural) if you like.

> As we discussed (offline), maybe rs6000-builtin-new.def is best (and at

> the end of this conversion, just move it).

+1
>

>>>> +     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 ;-)

>> Hm.  Well, vec_ld is a specific built-in, but this applies to a few more

>> than just that one.  But sure, if you want.

> "ldv" certainly is shorter and nicer in principle, but it is a bit

> cryptic.  As I said, it's probably not too hard to get used to it; and

> maybe a better name will present itself?

Maybe ldvec and stvec would serve without introducing specific builtin 
confusion.
>

>>>> +[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.

>> I rather prefer the way it is.  I do generate C code from this in the

>> subsequent patches.  But I like table-driven code to use things that

>> look like tables for input. :-)

> That's not what I meant...  Can you say

>    [TARGET_ALTIVEC && TARGET_64BIT]

> here?  Or even just

>    [!TARGET_ALTIVEC]

> or

>    [1]

> for always, or

>    [0]

> for never ("commented out").

Ah!  Sorry for misunderstanding.  Right now just an identifier is 
allowed, but we could certainly grab the whole string between the [] and 
drop it in with no concerns.  Hopefully we both remember when we get to 
the patch that reads the stanzas...
>

>>>> +  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?

>> I don't believe so, although there may be places where I forgot to allow

>> a line to be advanced -- that would be a bug, though, so let me know if

>> you see any.  Blank lines don't have any inherent meaning in the input

>> files.

> Not blank lines, I'm asking about newlines :-)  But those are not allowed

> to be inserted just anywhere, a line has to be one line, iiuc?


Yes.  Additional newlines can follow a newline, but the individual lines 
must contain everything that's expected in them.

Bill

>

>

> Segher
Segher Boessenkool Feb. 4, 2020, 11:48 p.m. | #5
On Tue, Feb 04, 2020 at 04:44:04PM -0600, Bill Schmidt wrote:
> >"ldv" certainly is shorter and nicer in principle, but it is a bit

> >cryptic.  As I said, it's probably not too hard to get used to it; and

> >maybe a better name will present itself?

> Maybe ldvec and stvec would serve without introducing specific builtin 

> confusion.


Let's go with that, if nothing better shows up.

> >That's not what I meant...  Can you say

> >   [TARGET_ALTIVEC && TARGET_64BIT]

> >here?  Or even just

> >   [!TARGET_ALTIVEC]

> >or

> >   [1]

> >for always, or

> >   [0]

> >for never ("commented out").

> Ah!  Sorry for misunderstanding.  Right now just an identifier is 

> allowed, but we could certainly grab the whole string between the [] and 

> drop it in with no concerns.  Hopefully we both remember when we get to 

> the patch that reads the stanzas...


:-)


Segher

Patch

diff --git a/gcc/config/rs6000/rs6000-genbif.c b/gcc/config/rs6000/rs6000-genbif.c
new file mode 100644
index 00000000000..a53209ed040
--- /dev/null
+++ b/gcc/config/rs6000/rs6000-genbif.c
@@ -0,0 +1,124 @@ 
+/* Generate built-in function initialization and recognition for Power.
+   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/>.  */
+
+/* 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
+
+   Both files group similar functions together in "stanzas," as
+   described below.
+
+   Each stanza in the built-in function file starts with a line
+   identifying the target mask for which the group of functions is
+   permitted, with the mask 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 "math";
+   <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.
+
+   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, such as these:
+
+     init    Process as a vec_init function
+     set     Process as a vec_set function
+     ext     Process as a vec_extract function
+     nosoft  Not valid with -msoft-float
+     ldv     Needs special handling for vec_ld semantics
+     stv     Needs special handling for vec_st semantics
+     reve    Needs special handling for element reversal
+     abs     Needs special handling for absolute value
+     pred    Needs special handling for comparison predicates
+     htm     Needs special handling for transactional memory
+
+   An example stanza might look like this:
+
+[TARGET_ALTIVEC]
+  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.
+
+   The overload file has more complex stanza headers.  Here the stanza
+   represents all functions with the same overloaded function name:
+
+     [<overload-id>, <external-name>, <internal-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; <external-name> is the
+   name that will appear as a #define in altivec.h; and <internal-name>
+   is the name that is overloaded in the back end.
+
+   Each function entry again has two lines.  The first line is again a
+   prototype line (this time without [kind]):
+
+     <return-type> <internal-name> (<argument-list>);
+
+   The second line contains only one token: the <bif-id> that this
+   particular instance of the overloaded function maps to.  It must
+   match a token that appears in the bif file.
+
+   An example stanza might look like this:
+
+[VEC_ABS, vec_abs, __builtin_vec_abs]
+  vector signed char __builtin_vec_abs (vector signed char);
+    ABS_V16QI
+  vector signed short __builtin_vec_abs (vector signed short);
+    ABS_V8HI
+
+  Blank lines may be used as desired in these files.  If it's desirable,
+  C-style comments are allowable provided that the file is run through
+  the preprocessor by the build system prior to feeding it to this
+  program.  */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <stdarg.h>
+#include <stdint.h>
+#include <ctype.h>
+#include <string.h>
+#include <assert.h>