From: Peter Bergner <bergner@linux.ibm.com>
To: "Kewen.Lin" <linkw@linux.ibm.com>, Carl Love <cel@us.ibm.com>
Cc: Segher Boessenkool <segher@kernel.crashing.org>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH v2] rs6000: Add buildin for mffscrn instructions
Date: Tue, 23 May 2023 17:30:48 -0500 [thread overview]
Message-ID: <fd006d63-8a27-cccd-8267-776601e122ab@linux.ibm.com> (raw)
In-Reply-To: <f18d0063-06a5-2b1f-ed9a-810e17815e49@linux.ibm.com>
On 5/23/23 12:24 AM, Kewen.Lin wrote:
> on 2023/5/23 01:31, Carl Love wrote:
>> The builtins were requested for use in GLibC. As of version 2.31 they
>> were added as inline asm. They requested a builtin so the asm could be
>> removed.
>
> So IMHO we also want the similar support for mffscrn, that is to make
> use of mffscrn and mffscrni on Power9 and later, but falls back to
> __builtin_set_fpscr_rn + mffs similar on older platforms.
So __builtin_set_fpscr_rn everything we want (sets the RN bits) and
uses mffscrn/mffscrni on P9 and later and uses older insns on pre-P9.
The only problem is we don't return the current FPSCR bits, as the bif
is defined to return void. Crazy idea, but could we extend the built-in
with an overload that returns the FPSCR bits? To be honest, I like
the __builtin_set_fpscr_rn name better than __builtin_mffscrn[i].
The built-in machinery can see that the usage is expecting a return value
or not and for the pre-P9 code, can skip generating the ending mffs if
we don't want the return value.
Peter
next prev parent reply other threads:[~2023-05-23 22:30 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 [this message]
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
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=fd006d63-8a27-cccd-8267-776601e122ab@linux.ibm.com \
--to=bergner@linux.ibm.com \
--cc=cel@us.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).