From: Aldy Hernandez <aldyh@redhat.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: GCC patches <gcc-patches@gcc.gnu.org>
Subject: Re: [COMMITTED] Convert nonzero mask in irange to wide_int.
Date: Tue, 4 Oct 2022 14:13:29 +0200 [thread overview]
Message-ID: <CAGm3qMW+8NjcFu99pkp5w2y9gdDHHfZ4Vfx6KEVQ4PdqkH8b3g@mail.gmail.com> (raw)
In-Reply-To: <CAGm3qMUCeLuJ-bBiURbmjwP1Z=02Zs+jeua0kg3qOUOTe+iPLw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2152 bytes --]
On Tue, Oct 4, 2022, 13:28 Aldy Hernandez <aldyh@redhat.com> wrote:
> On Tue, Oct 4, 2022 at 9:55 AM Richard Biener
> <richard.guenther@gmail.com> wrote:
> >
> >
> > Am 04.10.2022 um 09:36 schrieb Aldy Hernandez via Gcc-patches <
> gcc-patches@gcc.gnu.org>:
> > >
> > > The reason the nonzero mask was kept in a tree was basically inertia,
> > > as everything in irange is a tree. However, there's no need to keep
> > > it in a tree, as the conversions to and from wide ints are very
> > > annoying. That, plus special casing NULL masks to be -1 is prone
> > > to error.
> > >
> > > I have not only rewritten all the uses to assume a wide int, but
> > > have corrected a few places where we weren't propagating the masks, or
> > > rather pessimizing them to -1. This will become more important in
> > > upcoming patches where we make better use of the masks.
> > >
> > > Performance testing shows a trivial improvement in VRP, as things like
> > > irange::contains_p() are tied to a tree. Ughh, can't wait for trees in
> > > iranges to go away.
> >
> > You want trailing wide int storage though. A wide_int is quite large.
>
> Absolutely, this is only for short term storage. Any time we need
> long term storage, say global ranges in SSA_NAME_RANGE_INFO, we go
> through vrange_storage which will stream things in a more memory
> efficient manner. For irange, vrange_storage will stream all the
> sub-ranges, including the nonzero bitmask which is the first entry in
> such storage, as trailing_wide_ints.
>
> See irange_storage_slot to see how it lives in GC memory.
>
That being said, the ranger's internal cache uses iranges, albeit with a
squished down number of subranges (the minimum amount to represent the
range). So each cache entry will now be bigger by the difference between
one tree and one wide int.
I wonder if we should change the cache to use vrange_storage. If not now,
then when we convert all the subranges to wide ints.
Of course, the memory pressure of the cache is not nearly as problematic as
SSA_NAME_RANGE_INFO. The cache only stores names it cares about.
Aldy
next prev parent reply other threads:[~2022-10-04 12:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-04 7:35 Aldy Hernandez
2022-10-04 7:55 ` Richard Biener
2022-10-04 11:28 ` Aldy Hernandez
2022-10-04 12:13 ` Aldy Hernandez [this message]
2022-10-04 13:27 ` Andrew MacLeod
2022-10-04 14:30 ` Aldy Hernandez
2022-10-04 14:34 ` Richard Biener
2022-10-04 15:14 ` Aldy Hernandez
2022-10-04 15:42 ` Andrew MacLeod
2022-10-05 10:14 ` Aldy Hernandez
2022-10-07 9:23 ` Aldy Hernandez
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=CAGm3qMW+8NjcFu99pkp5w2y9gdDHHfZ4Vfx6KEVQ4PdqkH8b3g@mail.gmail.com \
--to=aldyh@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--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).