public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Edelsohn <dje@watson.ibm.com>
To: kenner@vlsi1.ultra.nyu.edu (Richard Kenner),
	Fariborz Jahanian <fjahanian@apple.com>
Cc: gcc@gcc.gnu.org
Subject: Re: Your assign_parms changes
Date: Thu, 18 Dec 2003 04:01:00 -0000	[thread overview]
Message-ID: <200312180155.hBI1tiT33946@makai.watson.ibm.com> (raw)
In-Reply-To: Message from kenner@vlsi1.ultra.nyu.edu (Richard Kenner)  of "Wed, 17 Dec 2003 19:10:56 EST." <10312180010.AA07225@vlsi1.ultra.nyu.edu>

>>>>> Richard Kenner writes:

Richard> On closer look, that's the only one that causes problems with max_parm_reg.
Richard> But I don't understand either of them.

Richard> The first change (revision 1.469) seems fine: you can store the group even 
Richard> if it's a CONCAT, at least I think so.  So I don't understand the second
Richard> change (1.472).  But the real problem appears to be that you set DECL_RTL
Richard> of a PARM_DECL to a REG (or CONCAT) but never update max_parm_regs.

	After reading the comments in the function, the mailinglist
archive can help shed more light on the patch, the authors of the patch
and the motivation for the patch.

	The patch is trying to prevent GCC from pessimizing code generated
for argument passing when the word size within the function is larger than
the word size specified in the ABI for argument passing.  For example,
passing a 64-bit long long int in two GPRs (each treated as 32-bits wide),
but utilizing 64-bit GPRs and 64-bit computation within the function.  If
the parameter is passed in two GPRs, GCC can form the 64-bit quantity
using register operations instead of using stack memory as an intermediate
location to concatenate the pieces.

	I guess we need to update max_parm_reg appropriately when we
allocate the new reg to operate as a parm within the function.

David

  reply	other threads:[~2003-12-18  1:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-18  1:57 Richard Kenner
2003-12-18  4:01 ` David Edelsohn [this message]
2003-12-18  4:28 Richard Kenner
2003-12-18  4:38 ` David Edelsohn

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=200312180155.hBI1tiT33946@makai.watson.ibm.com \
    --to=dje@watson.ibm.com \
    --cc=fjahanian@apple.com \
    --cc=gcc@gcc.gnu.org \
    --cc=kenner@vlsi1.ultra.nyu.edu \
    /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).