public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Richard Biener <richard.guenther@gmail.com>
Cc: Richard Biener <rguenther@suse.de>,
	Jiufu Guo <guojiufu@linux.ibm.com>,
	Jiufu Guo via Gcc-patches <gcc-patches@gcc.gnu.org>,
	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 13:52:08 -0600	[thread overview]
Message-ID: <20221223195207.GB25951@gate.crashing.org> (raw)
In-Reply-To: <E2B896DC-D44E-444C-B191-8758ACF894D5@gmail.com>

On Fri, Dec 23, 2022 at 08:13:48PM +0100, Richard Biener wrote:
> > Am 23.12.2022 um 17:55 schrieb Segher Boessenkool <segher@kernel.crashing.org>:
> > There are at least six very different kinds of subreg:
> > 
> > 0) Lvalue subregs.  Most archs have no use for it, and it can be
> >   expressed much more clearly and cleanly always.
> > 1) Subregs of mem.  Do not use, deprecated.  When old reload goes away
> >   this will go away.
> > 2) Subregs of hard registers.  Do not use, there are much better ways to
> >   write subregs of a non-zero byte offset, and for zero offset this is
> >   non-canonical RTL.
> > 3) Bitcast subregs.  In principle they go from one mode to another mode
> >   of the same size (but read on).
> > 4) Paradoxical subregs.  A concept completely separate from the rest,
> >   different rules for everything, it has to be special cased almost
> >   everywhere, it would be better if it was a separate rtx_code imo.
> > 5) Finally, normal subregs, taking a contiguous span of bits from some
> >   value.
> > 
> > Now, it is invalid to have a subreg of a subreg, so a 3) of a 5) is
> > written as just one subreg, as you say.  And a 4) of a 5) is just
> > invalid afaics (and let's not talk about 0)..2) anymore :-) )
> > 
> >> Note whether targets actually support subreg operations needs to be queried and I’m not sure how subreg with offset validation should work there.
> > 
> > But 3) is always valid, no?  On pseudos.
> 
> Yes, but it will eventually result in a spill/reload which is undesirable when we created this from CSE from a load.  So I think for CSE we do want to know whether a spill will definitely not occur.

Does it cause reloads though?  On any sane backend?  If no movsf pattern
allows integer registers, can things work at all?

Anyway, the normal way to test if some RTL is valid is to just generate
it (using validate_change) and then do apply_change_group, which then
cancels the changes if they do not work.  CSE already does some of this.

(I am doubtful doing any of this in CSE is a good idea fwiw).


Segher

  reply	other threads:[~2022-12-23 19:53 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 [this message]
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=20221223195207.GB25951@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 \
    --cc=richard.guenther@gmail.com \
    /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).