public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Jambor <mjambor@suse.cz>
To: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] ipa-cp: Fix check for exceeding param_ipa_cp_value_list_size (PR 113490)
Date: Wed, 24 Jan 2024 16:23:34 +0100	[thread overview]
Message-ID: <ri6a5oubvrd.fsf@> (raw)
In-Reply-To: <Za6fvTu_S0Oae03o@kam.mff.cuni.cz>

Hi,

On Mon, Jan 22 2024, Jan Hubicka wrote:
>> Hi,
>> 
>> When the check for exceeding param_ipa_cp_value_list_size limit was
>> modified to be ignored for generating values from self-recursive
>> calls, it should have been changed from equal to, to equals toor is
>> greater than.  This omission manifests itself as PR 113490.
>> 
>> When I examined the condition I also noticed that the parameter should
>> come from the callee rather than the caller, since the value list is
>> associated with the former and not the latter.  In practice the limit
>> is of course very likely to be the same, but I fixed this aspect of
>> the condition too.  I briefly audited all other uses of opt_for_fn in
>> ipa-cp.cc and all the others looked OK.
>> 
>> Bootstrapped and tested on x86_64-linux.  OK for master?
>> 
>> Thanks,
>> 
>> Martin
>> 
>> 
>> gcc/ChangeLog:
>> 
>> 2024-01-19  Martin Jambor  <mjambor@suse.cz>
>> 
>> 	PR ipa/113490
>> 	* ipa-cp.cc (ipcp_lattice<valtype>::add_value): Bail out if value
>> 	count is equal or greater than the limit.  Use the limit from the
>> 	callee.
>> 
>> gcc/testsuite/ChangeLog:
>> 
>> 2024-01-19  Martin Jambor  <mjambor@suse.cz>
>> 
>> 	PR ipa/113490
>> 	* gcc.dg/ipa/pr113490.c: New test.
> OK,
> thanks!

thank you, I have pushed the following, which has a tweak in the added
test so that it is only run on targets which support the required vectors.

Martin




When the check for exceeding param_ipa_cp_value_list_size limit was
modified to be ignored for generating values from self-recursive
calls, it should have been changed from equal to, to equals to or is
greater than.  This omission manifests itself as PR 113490.

When I examined the condition I also noticed that the parameter should
come from the callee rather than the caller, since the value list is
associated with the former and not the latter.  In practice the limit
is of course very likely to be the same, but I fixed this aspect of
the condition too.  I briefly audited all other uses of opt_for_fn in
ipa-cp.cc and all the others looked OK.

gcc/ChangeLog:

2024-01-19  Martin Jambor  <mjambor@suse.cz>

	PR ipa/113490
	* ipa-cp.cc (ipcp_lattice<valtype>::add_value): Bail out if value
	count is equal or greater than the limit.  Use the limit from the
	callee.

gcc/testsuite/ChangeLog:

2024-01-22  Martin Jambor  <mjambor@suse.cz>

	PR ipa/113490
	* gcc.dg/ipa/pr113490.c: New test.
---
 gcc/ipa-cp.cc                       |  2 +-
 gcc/testsuite/gcc.dg/ipa/pr113490.c | 31 +++++++++++++++++++++++++++++
 2 files changed, 32 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/ipa/pr113490.c

diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index b1e2a3a829a..e85477df32d 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -2298,7 +2298,7 @@ ipcp_lattice<valtype>::add_value (valtype newval, cgraph_edge *cs,
 	return false;
       }
 
-  if (!same_lat_gen_level && values_count == opt_for_fn (cs->caller->decl,
+  if (!same_lat_gen_level && values_count >= opt_for_fn (cs->callee->decl,
 						param_ipa_cp_value_list_size))
     {
       /* We can only free sources, not the values themselves, because sources
diff --git a/gcc/testsuite/gcc.dg/ipa/pr113490.c b/gcc/testsuite/gcc.dg/ipa/pr113490.c
new file mode 100644
index 00000000000..526e22b3787
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ipa/pr113490.c
@@ -0,0 +1,31 @@
+/* { dg-do compile { target int128 } } */
+/* { dg-options "-O3 -Wno-psabi"  } */
+
+typedef char A __attribute__((vector_size (64)));
+typedef short B __attribute__((vector_size (64)));
+typedef unsigned C __attribute__((vector_size (64)));
+typedef long D __attribute__((vector_size (64)));
+typedef __int128 E __attribute__((vector_size (64)));
+
+D bar1_D_0;
+E bar4 (A, D);
+
+E
+bar1 (C C_0)
+{
+  C_0 >>= 1;
+  bar4 ((A) C_0, bar1_D_0);
+  bar4 ((A) (E) {~0 }, (D) (A){ ~0 });
+  bar4 ((A) (B) { ~0 }, (D) (C) { ~0 });
+  bar1 ((C) (D)	{ 0, ~0});
+  bar4 ((A) C_0, bar1_D_0);
+  (A) { bar1 ((C) { 7})[5] - C_0[63], bar4 ((A) (D) {~0}, (D) (C) { 0, ~0})[3]};
+}
+
+E
+bar4 (A A_0, D D_0)
+{
+  bar1 ((C) A_0);
+  bar1 ((C) {5});
+  bar1 ((C) D_0);
+}
-- 
2.43.0


      reply	other threads:[~2024-01-24 15:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-20 20:52 Martin Jambor
2024-01-22 17:02 ` Jan Hubicka
2024-01-24 15:23   ` Martin Jambor [this message]

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=ri6a5oubvrd.fsf@ \
    --to=mjambor@suse.cz \
    --cc=gcc-patches@gcc.gnu.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).