From: Jiufu Guo <guojiufu@linux.ibm.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Jiufu Guo via Gcc-patches <gcc-patches@gcc.gnu.org>,
Richard Biener <rguenther@suse.de>,
dje.gcc@gmail.com, linkw@gcc.gnu.org, jeffreyalaw@gmail.com
Subject: Re: [PATCH] loading float member of parameter stored via int registers
Date: Tue, 27 Dec 2022 10:15:45 +0800 [thread overview]
Message-ID: <7epmc5fv72.fsf@pike.rch.stglabs.ibm.com> (raw)
In-Reply-To: <20221223144509.GZ25951@gate.crashing.org> (Segher Boessenkool's message of "Fri, 23 Dec 2022 08:45:09 -0600")
Hi,
Segher Boessenkool <segher@kernel.crashing.org> writes:
> Hi!
>
> On Fri, Dec 23, 2022 at 08:36:36PM +0800, Jiufu Guo wrote:
>> It seems some limitations there. e.g. 1. "subreg:DF on DI register"
>> may not work well on pseudo,
>
> It is perfectly normal:
> A hard register may be accessed in various modes throughout one
> function, but each pseudo register is given a natural mode
> and is accessed only in that mode. When it is necessary to describe
> an access to a pseudo register using a nonnatural mode, a @code{subreg}
> expression is used.
>
> and:
> @code{subreg} expressions are used to refer to a register in a machine
> mode other than its natural one, or to refer to one register of
> a multi-part @code{reg} that actually refers to several registers.
>
> Each pseudo register has a natural mode. If it is necessary to
> operate on it in a different mode, the register must be
> enclosed in a @code{subreg}.
>
> and we even have:
> @item hard registers
> It is seldom necessary to wrap hard registers in @code{subreg}s; such
> registers would normally reduce to a single @code{reg} rtx. This use of
> @code{subreg}s is discouraged and may not be supported in the future.
>
Thanks so much for detailed explaination!
>> and 2. to convert high-part:DI to SF,
>> a "shift/rotate" is needed, and then we need to "emit shift insn"
>> in cse. I may need to update this patch.
>
> Hrm. The machine insns to do this is just mtvsrd;xscvspdpn, but for
> converting the lowpart it is mtvsrws;xscvspdpn (this needs p9 or
> later). We should arrive at those patterns, and we should try to not
> go via the more expensive formulations with shifts, which don't describe
> the hardware well, and which overestimate the cost of it.
Yes, understant!
>
> None of this belongs in generic code at all imo. At expand time it
> should be expanded to something that works and can be optimised well,
> so not anything with :BLK (which has to be put in memory, something with
> unbounded size cannot be put in registers), not anything specifically
> tailored to any cpu, something nice and regular. Using a subreg (of a
> pseudo!) is the standard way of writing a bitcast.
>
> So generic code would do a (subreg:SF (reg:SI) 0) to express a 32-bit
> integer bitcast to an IEEE SP number, and our machine description should
> make it work nicely.
Right! So, I'm thinking a way: in generic code, we may generated
"shift+(subreg:SF (reg:SI) 0)"; and at somewhere (maybe in combiner),
using "mtvsr.." to replace the "shift+subreg".
BR,
Jeff (Jiufu)
>
>
> Segher
prev parent reply other threads:[~2022-12-27 2:15 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-21 6:27 Jiufu Guo
2022-12-21 7:30 ` Richard Biener
2022-12-22 7:25 ` guojiufu
2022-12-22 7:54 ` Richard Biener
2022-12-22 9:02 ` Jiufu Guo
2022-12-22 11:28 ` Richard Biener
2022-12-22 18:40 ` Segher Boessenkool
2022-12-23 12:23 ` Jiufu Guo
2022-12-23 12:36 ` Jiufu Guo
2022-12-23 14:45 ` Segher Boessenkool
2022-12-23 16:20 ` Richard Biener
2022-12-23 16:52 ` Segher Boessenkool
2022-12-23 19:13 ` Richard Biener
2022-12-23 19:52 ` Segher Boessenkool
2022-12-27 3:03 ` Jiufu Guo
2022-12-27 14:16 ` Jiufu Guo
2022-12-30 2:22 ` Jiufu Guo
2022-12-30 7:44 ` Segher Boessenkool
2022-12-30 8:30 ` Andrew Pinski
2023-01-03 3:28 ` Jiufu Guo
2023-01-03 8:59 ` Segher Boessenkool
2023-01-03 9:10 ` Hu, Lin1
2022-12-27 2:15 ` Jiufu Guo [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=7epmc5fv72.fsf@pike.rch.stglabs.ibm.com \
--to=guojiufu@linux.ibm.com \
--cc=dje.gcc@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jeffreyalaw@gmail.com \
--cc=linkw@gcc.gnu.org \
--cc=rguenther@suse.de \
--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).