public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Xi Ruoyao <xry111@xry111.site>
To: Jakub Jelinek <jakub@redhat.com>,
	Segher Boessenkool <segher@kernel.crashing.org>,
	David Edelsohn <dje.gcc@gmail.com>
Cc: gcc-patches@gcc.gnu.org,
	Tamar Christina <Tamar.Christina@arm.com>,
	 Andrew Pinski <apinski@marvell.com>
Subject: Re: [PATCH] rs6000: Canonicalize copysign (x, -1) back to -abs (x) in the backend [PR112606]
Date: Sat, 25 Nov 2023 18:42:56 +0800	[thread overview]
Message-ID: <60b5367881c834d1b0f7377a4f352c7c512e2d37.camel@xry111.site> (raw)
In-Reply-To: <ZWHJzN4hJHFSZ28f@tucnak>

On Sat, 2023-11-25 at 11:17 +0100, Jakub Jelinek wrote:
> The middle-end has been changed quite recently to canonicalize
> -abs (x) to copysign (x, -1) rather than the other way around.
> While I agree with that at GIMPLE level, since it matches the GIMPLE
> goal of as few operations as possible for a canonical form (-abs (x)
> is 2 GIMPLE statements, copysign (x, -1) is just one), I must say
> I don't really like that being done on RTL as well (or at least
> not canonicalizing (COPYSIGN x, negative) back to (NEG (ABS x))),
> because on most targets most of floating point constants need to be loaded
> from memory, there are a few exceptions but -1 is often not one of them.

On LoongArch fneg+fabs is even slower than loading a -1 from mem then do
copysign for some micro-architectural reason I don't know.  (FWIW on
LoongArch with LSX, the fastest way may be directly setting the sign bit
with LSX vbitseti instruction - it will also set the sign bits for
"junk" elements in the high bits of the vector register but there is no
harm.)

Can we make a target hook to control this?

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

  reply	other threads:[~2023-11-25 10:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-25 10:17 Jakub Jelinek
2023-11-25 10:42 ` Xi Ruoyao [this message]
2023-11-25 12:03   ` Tamar Christina
2023-11-25 12:09     ` Jakub Jelinek
2023-11-27  7:55       ` Tamar Christina
2023-11-27  8:12         ` Jakub Jelinek
2023-11-27  8:22           ` Tamar Christina
2023-12-04  8:35 ` Patch ping: " Jakub Jelinek
2023-12-04  9:21 ` Kewen.Lin

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=60b5367881c834d1b0f7377a4f352c7c512e2d37.camel@xry111.site \
    --to=xry111@xry111.site \
    --cc=Tamar.Christina@arm.com \
    --cc=apinski@marvell.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=segher@kernel.crashing.org \
    /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).