public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Bert Tenjy <tnggil@protonmail.com>
Cc: gcc-patches@gcc.gnu.org, dje.gcc@gmail.com, jakub@redhat.com,
	wschmidt@linux.ibm.com, tuliom@linux.ibm.com,
	Bert Tenjy <tnggil@gmail.com>
Subject: Re: [RFC PATCH v1 1/1] PPC64: Implement POWER Architecture Vector Function ABI.
Date: Thu, 13 Aug 2020 17:49:28 -0500	[thread overview]
Message-ID: <20200813224928.GJ6753@gate.crashing.org> (raw)
In-Reply-To: <1596832552-111518-1-git-send-email-tnggil@protonmail.com>

Hi!

This is about the Power binding to some OpenMP API, right?  It has
nothing to do with "vector" or "ABI" -- we have vectors already, and
we have ABIs already, more than enough of each.

It is very very VERY hard to review this without being told the proper
setting here.


On Fri, Aug 07, 2020 at 08:35:52PM +0000, Bert Tenjy wrote:
> This patch adds functionality to enable use of POWER Architecture's
> VSX extensions to speed up certain code sequences.

It does?  Oh, to implement some OpenMP stuff?

> The document describing POWER Architecture Vector Function interface is
> tentatively at: https://sourceware.org/glibc/wiki/Homepage?action=AttachFile&
> do=view&target=powerarchvectfuncabi.html

"This page does not exist yet. You can create a new empty page, or use
one of the page templates."

> 4. Changes to files vect-simd-clone-{1,4,5,8}.c are needed since 
> PPC64 has only 128bit-wide vector bus. x86_64 for which the tests were
> initially written has buses wider than that for AVX and higher architectures.

There is no "vector bus".  All Power vector registers are 128 bits, yes.

> 5. Per Segher's response to v0, we still need to agree a name for the 
> guiding document whose name is currently 'POWER Architecture Vector Function 
> ABI'.

Not just the document title.  You should use terminology that agrees with
everything else, that isn't usiing the same words for different things,
that isn't super confusing, throughout the patch :-)

> +/* Implement TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN.  */

The documentation for this hook says ((lack of) line wraps verbatim):

@deftypefn {Target Hook} int TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN (struct cgraph_node *@var{}, struct cgraph_simd_clone *@var{}, @var{tree}, @var{int})
This hook should set @var{vecsize_mangle}, @var{vecsize_int}, @var{vecsize_float}
fields in @var{simd_clone} structure pointed by @var{clone_info} argument and also
@var{simdlen} field if it was previously 0.
The hook should return 0 if SIMD clones shouldn't be emitted,
or number of @var{vecsize_mangle} variants that should be emitted.
@end deftypefn

so I have no idea what this hook should do.  Two of the four arguments
are left completely undefined, to start with.

> +
> +static int
> +rs6000_simd_clone_compute_vecsize_and_simdlen (struct cgraph_node *node,
> +                                        struct cgraph_simd_clone *clonei,
> +                                        tree base_type, int num)

Indent is wrong here, btw (should use tabs, and everything should align
to that first "struct"...)  You need to be a bit more creative here,
maybe use shorter function names to begin with?  And use names that say
what the functions are *for*, or giving some context.

"simd" means nothing here.  More than  half of our backend is SIMD
stuff.  That has only sideways to do with what you call "simd" here :-/

> +  tree t;
> +  int i;

Declare things at first use, *in* the first use if you can (you usually
can).

> +  bool decl_arg_p = (node->definition || type_arg_types == NULL_TREE);

This isn't a predicate, don't call it _p please.  It's a boolean, and
"decl_arg" isn't very meaningful either.

You might want to factor this differently altogether.

> +  for (t = (decl_arg_p ? DECL_ARGUMENTS (node->decl) : type_arg_types), i = 0;
> +       t && t != void_list_node; t = TREE_CHAIN (t), i++)

Do all that "i" stuff not in the "for" expression itself (but in the
body).  If a for expression doesn't fit on one line, it usually is more
readable if you put all three parts on separate lines.  Complex
initialisation like here is more readable if you do it *before* the
loop.

> +	case E_QImode:
> +	case E_HImode:
> +	case E_SImode:
> +	case E_DImode:
> +	case E_SFmode:
> +	case E_DFmode:

> +	  warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
> +		      "unsupported argument type %qT for simd", arg_type);

That isn't all types.  But you do ISA 2.07?  Put that in a comment
somewhere then please.

> +  if (TARGET_VSX)
> +    {
> +      clonei->vecsize_mangle = 'b';
> +      ret = 1;
> +    }

That is ISA 2.06 (Power 7), which you do not support I think?

> +  switch (clonei->vecsize_mangle)

I don't know what this is.

> +void
> +rs6000_simd_clone_adjust (struct cgraph_node *node)
> +{
> +}

Don't define it if it doesn't do anything?  Or is it required to exist
even if it doesn't ever do anything?

> +static int
> +rs6000_simd_clone_usable (struct cgraph_node *node)
> +{
> +  switch (node->simdclone->vecsize_mangle)
> +    {
> +      case 'b':

(wrong indentation, "case" should align with "{")

> +        if (!TARGET_VSX)
> +          return -1;
> +        return 0;
> +      default:
> +        gcc_unreachable ();
> +    }
> +}

Please don't use switch statements where a simple "if" would do.

static int
rs6000_simd_clone_usable (struct cgraph_node *node)
{
  gcc_assert (node->simdclone->vecsize_mangle == 'b');

  if (TARGET_VSX)
    return 0;

  return -1;
}

(If it looks too complicated, it probably is; don't remove whitelines to
make it shorter, that only makes things worse).


Anyway, please give some context in the proposed commit message: like
pointing to *what* it implements, and where that is described, and where
the binding is described.  And no dead links please ;-)


Segher

  parent reply	other threads:[~2020-08-13 22:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-07 20:35 Bert Tenjy
2020-08-07 20:59 ` Jakub Jelinek
2020-08-10 17:29   ` GT
2020-08-10 18:07     ` Jakub Jelinek
2020-08-13 20:40       ` GT
2020-08-13 21:00         ` Jakub Jelinek
2020-08-20 19:31           ` GT
2020-08-20 20:04             ` Jakub Jelinek
2020-08-20 20:29             ` Segher Boessenkool
2020-08-13 22:49 ` Segher Boessenkool [this message]
2020-08-17 17:44   ` GT
2020-08-17 21:28     ` Segher Boessenkool
2020-08-18 19:14       ` GT
2020-08-18 21:32         ` Segher Boessenkool
2020-08-20 16:19           ` GT
2020-08-20 17:48             ` Segher Boessenkool
2020-12-04 18:28               ` GT
2020-08-17 22:05     ` David Edelsohn
2020-08-17 23:06       ` Segher Boessenkool

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=20200813224928.GJ6753@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=tnggil@gmail.com \
    --cc=tnggil@protonmail.com \
    --cc=tuliom@linux.ibm.com \
    --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).