From: Andrew MacLeod <amacleod@redhat.com>
To: "Martin Liška" <mliska@suse.cz>,
"Richard Biener" <richard.guenther@gmail.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>, Aldy Hernandez <aldyh@redhat.com>
Subject: Re: [PATCH] Loop unswitching: support gswitch statements.
Date: Mon, 8 Nov 2021 13:34:57 -0500 [thread overview]
Message-ID: <d6b541d2-ad50-2f25-625a-4ea52d4aa79a@redhat.com> (raw)
In-Reply-To: <5c6c91d4-ed8b-8d98-2cd9-bafc84e6f2a4@suse.cz>
[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]
On 11/8/21 10:05 AM, Martin Liška wrote:
> On 9/28/21 22:39, Andrew MacLeod wrote:
>> In Theory, modifying the IL should be fine, it happens already in
>> places, but its not extensively tested under those conditions yet.
>
> Hello Andrew.
>
> I've just tried using a global gimple_ranger and it crashes when loop
> unswitching duplicates
> some BBs.
>
ah, ok, so the default on-entry cache for ranger doesn't expect to see
the number of BBs to increase. . I can change this to grow, but I want
to avoid too many grows. This test case looks like it grows the number
of BBs from 24 to somewhere north of 90.. Do you have any idea in
advance how many BBs you will be adding? Although Im not sure how to
make such a suggestion anyway . Ill work something out. The sparse
cache has no such issue, but you will lose precision so we don't want to
trigger on that anyway.
As work around for the moment to keep you going, heres a patch which
simply starts with 256 extra spaces, so that should allow you to
continue while I fix this properly to grow. and you can see if things
continue to work as expected. You can increase that number as you see fit
I'll put in a proper fix in a bit.
[-- Attachment #2: m.patch --]
[-- Type: text/x-patch, Size: 577 bytes --]
diff --git a/gcc/gimple-range-cache.cc b/gcc/gimple-range-cache.cc
index e5591bab0ef..6a3dcfadf98 100644
--- a/gcc/gimple-range-cache.cc
+++ b/gcc/gimple-range-cache.cc
@@ -220,7 +220,7 @@ sbr_vector::sbr_vector (tree t, irange_allocator *allocator)
gcc_checking_assert (TYPE_P (t));
m_type = t;
m_irange_allocator = allocator;
- m_tab_size = last_basic_block_for_fn (cfun) + 1;
+ m_tab_size = last_basic_block_for_fn (cfun) + 256;
m_tab = (irange **)allocator->get_memory (m_tab_size * sizeof (irange *));
memset (m_tab, 0, m_tab_size * sizeof (irange *));
next prev parent reply other threads:[~2021-11-08 18:35 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-15 8:46 Martin Liška
2021-09-19 16:50 ` Jeff Law
2021-09-28 11:50 ` Richard Biener
2021-09-28 20:39 ` Andrew MacLeod
2021-09-29 8:43 ` Richard Biener
2021-09-29 15:20 ` Andrew MacLeod
2021-09-29 15:28 ` Jeff Law
2021-09-29 15:59 ` Andrew MacLeod
2021-09-30 7:33 ` Richard Biener
2021-11-08 15:05 ` Martin Liška
2021-11-08 18:34 ` Andrew MacLeod [this message]
2021-11-08 19:45 ` Andrew MacLeod
2021-11-09 13:37 ` Richard Biener
2021-11-09 16:41 ` Andrew MacLeod
2021-11-10 7:52 ` Aldy Hernandez
2021-11-10 8:50 ` Richard Biener
2021-11-09 16:44 ` Martin Liška
2021-11-10 8:59 ` Richard Biener
2021-11-10 13:29 ` Martin Liška
2021-11-11 7:15 ` Richard Biener
2021-11-16 13:53 ` Martin Liška
2021-11-19 9:49 ` Richard Biener
2021-11-16 14:40 ` Martin Liška
2021-11-19 10:00 ` Richard Biener
2021-11-22 15:06 ` Martin Liška
2021-11-23 13:58 ` Richard Biener
2021-11-23 15:20 ` Martin Liška
2021-11-23 16:36 ` Martin Liška
2021-11-24 8:00 ` Richard Biener
2021-11-24 10:48 ` Martin Liška
2021-11-24 12:48 ` Richard Biener
2021-11-24 14:14 ` Martin Liška
2021-11-24 14:32 ` Martin Liška
2021-11-26 8:12 ` Richard Biener
2021-11-29 12:45 ` Martin Liška
2021-11-30 11:17 ` Richard Biener
2021-12-01 14:10 ` Martin Liška
2021-12-01 14:19 ` Richard Biener
2021-12-01 14:25 ` Martin Liška
2021-12-01 14:34 ` Richard Biener
2021-12-01 14:48 ` Martin Liška
2021-12-01 18:21 ` Andrew MacLeod
2021-12-02 11:45 ` Martin Liška
2021-12-02 12:01 ` Richard Biener
2021-12-02 13:10 ` Martin Liška
2021-12-02 13:46 ` Richard Biener
2021-12-08 21:06 ` Andrew MacLeod
2021-12-02 14:27 ` Andrew MacLeod
2021-12-02 16:02 ` Martin Liška
2021-12-03 14:09 ` Andrew MacLeod
2021-12-09 12:59 ` Martin Liška
2021-12-09 14:44 ` Andrew MacLeod
2021-12-09 13:02 ` Martin Liška
2022-01-05 12:34 ` Richard Biener
2022-01-06 15:11 ` Andrew MacLeod
2022-01-06 16:02 ` Martin Liška
2022-01-06 16:20 ` Andrew MacLeod
2022-01-06 16:35 ` Martin Liška
2022-01-06 16:42 ` Andrew MacLeod
2022-01-06 16:32 ` Andrew MacLeod
2022-01-06 16:30 ` Martin Liška
2022-01-13 16:01 ` Martin Liška
2022-01-14 7:23 ` Richard Biener
2021-11-25 10:38 ` Aldy Hernandez
2021-11-26 7:45 ` Richard Biener
2021-11-24 7:46 ` Richard Biener
2021-10-05 17:08 ` Andrew MacLeod
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=d6b541d2-ad50-2f25-625a-4ea52d4aa79a@redhat.com \
--to=amacleod@redhat.com \
--cc=aldyh@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=mliska@suse.cz \
--cc=richard.guenther@gmail.com \
/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).