public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: "Kewen.Lin" <linkw@linux.ibm.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
	David Edelsohn <dje.gcc@gmail.com>,
	Peter Bergner <bergner@linux.ibm.com>,
	Michael Meissner <meissner@linux.ibm.com>
Subject: Re: [PATCH 1/2] rs6000: Emit vector fp comparison directly in rs6000_emit_vector_compare
Date: Sun, 27 Nov 2022 12:16:27 -0600	[thread overview]
Message-ID: <20221127181627.GL25951@gate.crashing.org> (raw)
In-Reply-To: <7ccd6eda-8d29-8e41-6e9f-041097eee42e@linux.ibm.com>

Hi!

Whoops I missed following up to this.

On Mon, Nov 21, 2022 at 10:01:14AM +0800, Kewen.Lin wrote:
> on 2022/11/18 23:10, Segher Boessenkool wrote:
> > ge is nasty for float, it means something different with and without
> > -ffast-math (with fast-math ge means not lt, le means not gt; both can
> > be done with a simple single condition, no cror needed.  (Compare to ne
> > which is the same with and without -ffast-math, that is because it has a
> > "not" in its definition!)
> 
> It's true for scalar float comparison, but the context here is for vector
> comparison, the result of comparison is still vector (of boolean), and we
> have the corresponding vector comparison instruction for ge, so I think it
> should be fine here.

It is fine if all contexts it is used in allow ge insns, sure.  But you
have to make sure that is true; ge still is nasty, it truly means
something different with fastmath (which applies to vector float just\
the same as it does to scalar float).

> > Thanks for the explanation!
> > 
> > Can you do this in multiple steps, which will make it much easier to
> > review, and to spot the problem if some unexpected problem shows up?
> 
> Sure, I'll try my best to separate it into some steps and show how it
> evolves gradually.

If you can make the bulk of the series not actually change code
generation, just rearrange and massage the compiler code, that is much
easier to review (and it also helps to spot the problems in if there are
regressions, as a bonus).

Cheers,


Segher

      reply	other threads:[~2022-11-27 18:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-16  6:48 Kewen.Lin
2022-11-16  6:51 ` [PATCH 2/2] rs6000: Refine integer comparison handlings " Kewen.Lin
2022-11-16 18:58   ` Segher Boessenkool
2022-11-17  7:52     ` Kewen.Lin
2022-11-18 15:18       ` Segher Boessenkool
2022-11-16 18:44 ` [PATCH 1/2] rs6000: Emit vector fp comparison directly " Segher Boessenkool
2022-11-17  6:59   ` Kewen.Lin
2022-11-18 15:10     ` Segher Boessenkool
2022-11-21  2:01       ` Kewen.Lin
2022-11-27 18:16         ` 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=20221127181627.GL25951@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=linkw@linux.ibm.com \
    --cc=meissner@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).