public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Michael Meissner <meissner@linux.ibm.com>,
	gcc-patches@gcc.gnu.org, David Edelsohn <dje.gcc@gmail.com>,
	Bill Schmidt <wschmidt@linux.ibm.com>,
	Peter Bergner <bergner@linux.ibm.com>,
	Will Schmidt <will_schmidt@vnet.ibm.com>
Subject: Re: [PATCH 3/3] Add IEEE 128-bit fp conditional move on PowerPC.
Date: Wed, 30 Jun 2021 14:07:09 -0500	[thread overview]
Message-ID: <20210630190709.GD1583@gate.crashing.org> (raw)
In-Reply-To: <20210609002447.GC18854@ibm-toto.the-meissners.org>

Hi!

On Tue, Jun 08, 2021 at 08:24:47PM -0400, Michael Meissner wrote:
> In this patch, I simplified things compared to previous patches.  Instead of
> allowing any four of the modes to be used for the conditional move comparison
> and the move itself could use different modes, I restricted the conditional
> move to just the same mode.  I.e. you can do:
> 
>         _Float128 a, b, c, d, e, r;
> 
>         r = (a == b) ? c : d;
> 
> But you can't do:
> 
>         _Float128 c, d, r;
>         double a, b;
> 
>         r = (a == b) ? c : d;
> 
> or:
> 
>         _Float128 a, b;
>         double c, d, r;
> 
>         r = (a == b) ? c : d;

I suspect you mean you *can* do it, but it generates sub-optimal code
for it, promoting everything to QP float?

> This eliminates a lot of the complexity of the code, because you don't have to
> worry about the sizes being different, and the IEEE 128-bit types being
> restricted to Altivec registers, while the SF/DF modes can use any VSX
> register.

It doesn't remove any complexity.  Instead, you postpone having to work
on it to a later date.  Pootentially making it harder for the person who
will eventually have to do it to do a good job :-(

(Or this code is not worth having in the first place, in which case, why
do we want to have it?)

Of course this is the more common case, but it is not so overwhelmingly
more common that we can ignore the rest.

> Compared to the May 18th patches, this patch replaces the complicated test that
> was complained about.

That was explained to you to not be a good idea.  Yes.

> @@ -15783,6 +15784,35 @@ rs6000_maybe_emit_fp_cmove (rtx dest, rtx op, rtx true_cond, rtx false_cond)
>    if (!can_create_pseudo_p ())
>      return 0;
>  
> +  /* We allow the comparison to be either SFmode/DFmode and the true/false
> +     condition to be either SFmode/DFmode.  I.e. we allow:
> +
> +	float a, b;
> +	double c, d, r;
> +
> +	r = (a == b) ? c : d;
> +
> +    and:
> +
> +	double a, b;
> +	float c, d, r;
> +
> +	r = (a == b) ? c : d;
> +
> +    but we don't allow intermixing the IEEE 128-bit floating point types with
> +    the 32/64-bit scalar types.
> +
> +    It gets too messy where SFmode/DFmode can use any register and TFmode/KFmode
> +    can only use Altivec registers.  In addtion, we would need to do a XXPERMDI

(spelling: "addition", "an").

Lose the "gets too messy" comment, people might believe it!

> +  if (compare_mode == result_mode
> +      || (compare_mode == SFmode && result_mode == DFmode)
> +      || (compare_mode == DFmode && result_mode == SFmode))
> +    ;
> +  else
> +    return false;

Use a logical inversion, instead, as said before:

  if (!(compare_mode == result_mode
	|| (compare_mode == SFmode && result_mode == DFmode)
	|| (compare_mode == DFmode && result_mode == SFmode)))
    return false;

> +;; Support for ISA 3.1 IEEE 128-bit conditional move.  The mode used in the
> +;; comparison must be the same as used in the conditional move.

s/conditional //

Okay for trunk with those fixes.  Also okay for 11 after the usual wait.
Thanks!


Segher

      parent reply	other threads:[~2021-06-30 19:08 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-09  0:17 [PATCH 0/3] Add Power10 IEEE 128-bit min, max, conditional move Michael Meissner
2021-06-09  0:21 ` [PATCH 1/3] Add IEEE 128-bit min/max support on PowerPC Michael Meissner
2021-06-17  0:32   ` Ping: " Michael Meissner
2021-06-17 17:39   ` Segher Boessenkool
2021-06-17 19:18     ` Michael Meissner
2021-06-23 23:56       ` Segher Boessenkool
2021-06-28 19:00         ` Michael Meissner
2021-06-30 17:35           ` Segher Boessenkool
2021-06-09  0:22 ` [PATCH 2/3] Fix IEEE 128-bit min/max test Michael Meissner
2021-06-17  0:33   ` Ping: " Michael Meissner
2021-06-17 18:11   ` Segher Boessenkool
2021-06-17 19:24     ` Michael Meissner
2021-06-17 20:11     ` Michael Meissner
2021-06-25 17:46       ` Segher Boessenkool
2021-06-28 18:41         ` Michael Meissner
2021-06-17 22:56     ` [PATCH 2/3 V2] " Michael Meissner
2021-06-23 19:08       ` Ping: " Michael Meissner
2021-06-23 19:20         ` Michael Meissner
2021-06-30  0:06       ` Segher Boessenkool
2021-06-30 16:25         ` Michael Meissner
2021-06-09  0:24 ` [PATCH 3/3] Add IEEE 128-bit fp conditional move on PowerPC Michael Meissner
2021-06-17  0:34   ` Ping: " Michael Meissner
2021-06-23 19:09   ` Michael Meissner
2021-06-30 19:07   ` Segher Boessenkool [this message]

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=20210630190709.GD1583@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=meissner@linux.ibm.com \
    --cc=will_schmidt@vnet.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).