public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Jiufu Guo <guojiufu@linux.ibm.com>
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: Fri, 23 Dec 2022 08:45:09 -0600	[thread overview]
Message-ID: <20221223144509.GZ25951@gate.crashing.org> (raw)
In-Reply-To: <7ev8m2fga3.fsf@pike.rch.stglabs.ibm.com>

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.

> 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.

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.


Segher

  reply	other threads:[~2022-12-23 14:46 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 [this message]
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

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=20221223144509.GZ25951@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=guojiufu@linux.ibm.com \
    --cc=jeffreyalaw@gmail.com \
    --cc=linkw@gcc.gnu.org \
    --cc=rguenther@suse.de \
    /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).