public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
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 20:13:48 +0100	[thread overview]
Message-ID: <E2B896DC-D44E-444C-B191-8758ACF894D5@gmail.com> (raw)
In-Reply-To: <20221223165239.GA25951@gate.crashing.org>



> Am 23.12.2022 um 17:55 schrieb Segher Boessenkool <segher@kernel.crashing.org>:
> 
> On Fri, Dec 23, 2022 at 05:20:09PM +0100, Richard Biener wrote:
>>>> Am 23.12.2022 um 15:48 schrieb Segher Boessenkool <segher@kernel.crashing.org>:
>>> 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.
>> 
>> There’s also a byte offset in subreg, so (subreg:sf (reg:di) 4) is a Highpart bitcast.
> 
> 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.

Richard 
> 
> Segher

  reply	other threads:[~2022-12-23 19:14 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 [this message]
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=E2B896DC-D44E-444C-B191-8758ACF894D5@gmail.com \
    --to=richard.guenther@gmail.com \
    --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=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).