public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: "Kewen.Lin" <linkw@linux.ibm.com>
Cc: Ajit Agarwal <aagarwa1@linux.ibm.com>,
	Peter Bergner <bergner@linux.ibm.com>,
	Segher Boessenkool <segher@kernel.crashing.org>,
	David Edelsohn <dje.gcc@gmail.com>,
	Michael Meissner <meissner@linux.ibm.com>,
	gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH v2] rs6000: Stackoverflow in optimized code on PPC [PR100799]
Date: Tue, 2 Apr 2024 10:03:19 +0200	[thread overview]
Message-ID: <Zgu7xwOj24mArDdu@tucnak> (raw)
In-Reply-To: <d007c7d6-73e5-4961-aa46-590f4800977a@linux.ibm.com>

On Tue, Apr 02, 2024 at 02:12:04PM +0800, Kewen.Lin wrote:
> >>>> The old code for the unused hidden parameter (which was the 9th param) would
> >>>> fall thru to the "return NULL_RTX;" which would make the callee assume there
> >>>> was a parameter save area allocated.  Now instead, we'll return a reg rtx,
> >>>> probably of r11 (r3 thru r10 are our param regs) and I'm guessing we'll now
> >>>> see a copy of r11 into a pseudo like we do for the other param regs.
> >>>> Is that a problem? Given it's an unused parameter, it'll probably get deleted
> >>>> as dead code, but could it cause any issues?  What if we have more than one
> 
> I think Peter raised one good point, not sure it would really cause some issues,
> but the assigned reg goes beyond GP_ARG_MAX_REG, at least it is confusing to people
> especially without DCE like at -O0.  Can we aggressively remove these candidates
> from DECL_ARGUMENTS chain?  Does it cause any assertion to fail?

I'd prefer not to remove DECL_ARGUMENTS chains, they are valid arguments that just some
invalid code doesn't pass.  By removing them you basically always create an
invalid case, this time in the other direction, valid caller passes more
arguments than the callee (invalidly) expects.

	Jakub


  reply	other threads:[~2024-04-02  8:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-22 10:15 Ajit Agarwal
2024-03-23  4:37 ` Peter Bergner
2024-03-23  9:33   ` Ajit Agarwal
2024-03-23 14:28     ` Ajit Agarwal
2024-03-23 16:03     ` Peter Bergner
2024-03-23 18:37       ` Ajit Agarwal
2024-04-02  6:12         ` Kewen.Lin
2024-04-02  8:03           ` Jakub Jelinek [this message]
2024-04-03  5:18             ` Kewen.Lin
2024-04-03  8:35               ` Jakub Jelinek
2024-04-03  9:02                 ` Kewen.Lin
2024-04-03  9:23                   ` Jakub Jelinek
2024-04-03 11:01                     ` Kewen.Lin
2024-04-03 11:18                       ` Jakub Jelinek
2024-04-03 12:18                         ` Kewen.Lin

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=Zgu7xwOj24mArDdu@tucnak \
    --to=jakub@redhat.com \
    --cc=aagarwa1@linux.ibm.com \
    --cc=bergner@linux.ibm.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=linkw@linux.ibm.com \
    --cc=meissner@linux.ibm.com \
    --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).