public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Carl Love <cel@us.ibm.com>
To: "Kewen.Lin" <linkw@linux.ibm.com>,
	Segher Boessenkool <segher@kernel.crashing.org>
Cc: gcc-patches@gcc.gnu.org, Peter Bergner <bergner@linux.ibm.com>,
	cel@us.ibm.com
Subject: Re: [PATCH v2] rs6000: Add buildin for mffscrn instructions
Date: Wed, 31 May 2023 08:36:09 -0700	[thread overview]
Message-ID: <522aa2ef126fd2cc45639fefcff778a8a3737d96.camel@us.ibm.com> (raw)
In-Reply-To: <ddfc072a-8d1e-acf6-321b-45d0c173eaaf@linux.ibm.com>

Kewen:

On Wed, 2023-05-31 at 17:11 +0800, Kewen.Lin wrote:
> > So, there is no need for the builtin to have to determine if the
> > user
> > is storing the result of the __builtin_set_fpscr_rn.  The RN bits
> > will
> > always be updated by the __builtin_set_fpscr_rn builtin and the
> > existing fields of the FPSCR will always be returned by the
> > builtin.
> 
> Yeah, I agree, even with pre-P9 code when the returned value is
> unused,
> I'd expect DCE can eliminate the part for the FPSCR bits reading and
> masking, it's just like before (only setting RN bits).
> 
> The only concern I mentioned before is the built-in name doesn't
> clearly
> match what it does (with extending, it returns something instead)
> since
> it's only saying "set" and setting RN bits, the return value is
> easily
> misunderstood as returning old RN bits, the documentation has to
> explain
> and note it well.
> 
> Looking forward to Segher's opinion on this.

I have the patch to extend the __builtin_set_fpscr_rn builtin working. 
I agree the documentation on the instructions in the ISA is not really
clear about that.  It needs to be much more explicit in the builtin
description that the current RN field is returned then the field is
updated with the new RN bits from the argument.  

I sent the patch, with the updated builtin description and testcases to
the GLibC team to see what they thought of it.  The goal was for the
builtin to be effectively a "drop in replacement" for the inline asm
that they have.  I was planning on posting the new version if the GLibC
team says it works for them.  Hopefully I will hear from them soon.

                    Carl 


  reply	other threads:[~2023-05-31 15:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-13 20:47 [PATCH] " Carl Love
2023-05-18 21:12 ` [PATCH v2] " Carl Love
2023-05-22  6:36   ` Kewen.Lin
2023-05-22 17:31     ` Carl Love
2023-05-23  5:24       ` Kewen.Lin
2023-05-23 22:30         ` Peter Bergner
2023-05-24  5:32           ` Kewen.Lin
2023-05-24 15:20             ` Carl Love
2023-05-24 16:32               ` Peter Bergner
2023-05-25  5:28               ` Kewen.Lin
2023-05-25 15:59                 ` Carl Love
2023-05-31  9:11                   ` Kewen.Lin
2023-05-31 15:36                     ` Carl Love [this message]
2023-05-22 17:36     ` [PATCH v3] " Carl Love

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=522aa2ef126fd2cc45639fefcff778a8a3737d96.camel@us.ibm.com \
    --to=cel@us.ibm.com \
    --cc=bergner@linux.ibm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=linkw@linux.ibm.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).