public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: will schmidt <will_schmidt@vnet.ibm.com>
Cc: gcc-patches@gcc.gnu.org, David Edelsohn <dje.gcc@gmail.com>,
	Peter Bergner <bergner@linux.ibm.com>
Subject: Re: rs6000:  RFC/Update support for addg6s instruction.  PR100693
Date: Wed, 16 Mar 2022 13:12:49 -0500	[thread overview]
Message-ID: <20220316181249.GK614@gate.crashing.org> (raw)
In-Reply-To: <3b4976974ca4a9e481c462ef2b9a4892f1d4174f.camel@vnet.ibm.com>

Hi!

On Wed, Mar 16, 2022 at 12:20:18PM -0500, will schmidt wrote:
> For PR100693, we currently provide an addg6s builtin using unsigned
> int arguments, but we are missing an unsigned long long argument
> equivalent.  This patch adds an overload to provide the long long
> version of the builtin.
> 
> unsigned long long __builtin_addg6s (unsigned long long, unsigned long long);
> 
> RFC/concerns: This patch works, but looking briefly at intermediate stages
> is not behaving quite as I expected.   Looking at the intermediate dumps, I
> see in pr100693.original that calls I expect to be routed to the internal
> __builtin_addg6s_si() that uses (unsigned int) arguments are instead being
> handled by __builtin_addg6s_di() with casts that convert the arguments to
> (unsigned long long).

Did you test with actual 32-bit variables, instead of just function
arguments?  Function arguments are always passed in (sign-extended)
registers.

Like,

unsigned int f(unsigned int *a, unsigned int *b)
{
	return __builtin_addg6s(*a, *b);
}

> As a test, I see if I swap the order of the builtins in rs6000-overload.def
> I end up with code casting the ULL values to UI, which provides truncated
> results, and is similar to what occurs today without this patch.
> 
> All that said, this patch seems to work.  OK for next stage 1?
> Tested on power8BE as well as LE power8,power9,power10.

Please ask again when stage 1 has started?

> gcc/
> 	PR target/100693
> 	* config/rs6000/rs600-builtins.def: Remove entry for __builtin_addgs()
> 	  and add entries for __builtin_addg6s_di() and __builtin_addg6s_si().

Indent of second and further lines should be at the "*", not two spaces
after that.

> -   UNSPEC_ADDG6S
> +   UNSPEC_ADDG6S_SI
> +   UNSPEC_ADDG6S_DI

You do not need multiple unspec numbers.  You can differentiate them
based on the modes of the arguments, already :-)

>  ;; Miscellaneous ISA 2.06 (power7) instructions
> -(define_insn "addg6s"
> +(define_insn "addg6s_si"
>    [(set (match_operand:SI 0 "register_operand" "=r")
>  	(unspec:SI [(match_operand:SI 1 "register_operand" "r")
>  		    (match_operand:SI 2 "register_operand" "r")]
> -		   UNSPEC_ADDG6S))]
> +		   UNSPEC_ADDG6S_SI))]
> +  "TARGET_POPCNTD"
> +  "addg6s %0,%1,%2"
> +  [(set_attr "type" "integer")])
> +
> +(define_insn "addg6s_di"
> +  [(set (match_operand:DI 0 "register_operand" "=r")
> +	(unspec:DI [(match_operand:DI 1 "register_operand" "r")
> +		    (match_operand:DI 2 "register_operand" "r")]
> +		   UNSPEC_ADDG6S_DI))]
>    "TARGET_POPCNTD"
>    "addg6s %0,%1,%2"
>    [(set_attr "type" "integer")])

(define_insn "addg6s"
  [(set (match_operand:GPR 0 "register_operand" "=r")
	(unspec:GPR [(match_operand:GPR 1 "register_operand" "r")
		     (match_operand:GPR 2 "register_operand" "r")]
		    UNSPEC_ADDG6S))]
  "TARGET_POPCNTD"
  "addg6s %0,%1,%2"
  [(set_attr "type" "integer")])

We do not want DI (here, and in most places) for -m32!

> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr100693.c
> @@ -0,0 +1,68 @@
> +/* { dg-do compile { target { powerpc*-*-linux* } } } */

Why only on Linux?

> +/* { dg-skip-if "" { powerpc*-*-darwin* } } */

Why not on Darwin?  And why skip it anyway, given the previous line :-)

> +/* { dg-require-effective-target powerpc_vsx_ok } */

That is the wrong requirement.  You want to test for Power7, not for
VSX.  I realise you probably copied this from elsewhere :-(  (If from
another addg6s testcase, just keep it).


Segher

  reply	other threads:[~2022-03-16 18:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-16 17:20 will schmidt
2022-03-16 18:12 ` Segher Boessenkool [this message]
2022-03-16 20:06   ` will schmidt
2022-03-16 20:59     ` 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=20220316181249.GK614@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=bergner@linux.ibm.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=will_schmidt@vnet.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).