public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <jeffreyalaw@gmail.com>
To: Jiufu Guo <guojiufu@linux.ibm.com>,
	Jiufu Guo via Gcc-patches <gcc-patches@gcc.gnu.org>
Cc: segher@kernel.crashing.org, dje.gcc@gmail.com, linkw@gcc.gnu.org,
	rguenther@suse.de
Subject: Re: Ping^^: [PATCH V2] extract DF/SF/SI/HI/QI subreg from parameter word on stack
Date: Sat, 10 Jun 2023 11:40:44 -0600	[thread overview]
Message-ID: <cb8a085b-9134-4e8c-58a4-286861715e10@gmail.com> (raw)
In-Reply-To: <7nr0rnbr5q.fsf_-_@ltcden2-lp1.aus.stglabs.ibm.com>



On 5/10/23 19:20, Jiufu Guo wrote:
> 
> Hi,
> 
> I would like to ping:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609396.html
> 
> We know there are a few issues related to aggregate parameter and
> returns.  I'm thinking if it is ok for trunk to use this patch to
> resolve part of those issues.
It looks like the patch is focused on emitting a load of the object from 
memory into a GPR, then copying the GPR into pseudo (which hopefully 
gets allocated into an FPR).  That would seem to indicate the value got 
flushed to memory at some point.  Presumably because the type of the 
object it not one that we would typically allow in registers, except for 
some special cases for parameter passing and return values?

If that's the case, then is there any value in finding the flush to the 
stack and just emitting a copy from the GPR into the destination pseudo 
at that point?

Or is it just easier to construct a load from the flushback area and let 
CSE/DCE/DSE clean things up?

Jeff

I

  reply	other threads:[~2023-06-10 17:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-04 13:45 Jiufu Guo
2023-03-02  9:33 ` Ping: " Jiufu Guo
2023-05-11  1:20   ` Ping^^: " Jiufu Guo
2023-06-10 17:40     ` Jeff Law [this message]
2023-06-13  2:58       ` 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=cb8a085b-9134-4e8c-58a4-286861715e10@gmail.com \
    --to=jeffreyalaw@gmail.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=guojiufu@linux.ibm.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).