From: "Richard Guenther" <richard.guenther@gmail.com>
To: "Diego Novillo" <dnovillo@google.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: Fix PR 33870
Date: Wed, 14 Nov 2007 14:07:00 -0000 [thread overview]
Message-ID: <84fc9c000711140446l74fc9b36l4bfc2f024a21a66f@mail.gmail.com> (raw)
In-Reply-To: <473AECED.3010804@google.com>
On Nov 14, 2007 1:41 PM, Diego Novillo <dnovillo@google.com> wrote:
> Richard Guenther wrote:
>
> > No, we are limiting all pointed-to SFTs of all structs (maybe this was not
> > intended, but it is necessary) out of the partitioner.
>
> *All* of them? That's a bug. Only the first one inside a nested
> structure should be limited.
Yes, for
struct X {
int i;
} m;
the SFT for &m.i; has nesting level 1. And this is required - see the example
with the toplevel array that is still failing.
> > but clearly you are growing the numer of symbols in NMTs
> > (the regression is not as bad as for my initial patch, but is the least
> > regression we can have there if we want to fix the miscompilation this way).
>
> Yes, but we should only be adding as many SFTs as nested structures we
> have. So, to give you a ridiculous example, if we had a structure with
> 300 fields and 2 nested structures, we should only have 2
> unpartitionable SFTs (the first one of each nested structure).
Huh? No, all pointed-to SFTs are unpartitionable. So,
struct X {
struct Y {
int i1;
int i2;
...
&i1;
&i2;
...
makes all SFTs that belong to i1, i2, etc. unpartitionable. At least that's
how your code works ;)
I guess in add_uids_for_ptset instead of
! if (SFT_NESTING_LEVEL (sft) > 0)
! SFT_UNPARTITIONABLE_P (sft) = true;
we can get away with only doing that if the type of the SFT itself could
have subvariables (which is probably again what you intended?).
> > We enlarge the NMT aliased symbols. (And obviously we can now create
> > aritifical testcases with any number of aliased SFTs remaining on a stmt,
> > I'll come up with one of those for you)
>
> Thanks. The secret here is going to be one where we are marking way too
> many SFTs as unpartitionable. My contention is that we shouldn't be
> doing this too often. If we are, that's the bug.
Probably the latter then.
Richard.
next prev parent reply other threads:[~2007-11-14 12:46 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-08 0:24 Diego Novillo
2007-11-08 0:35 ` Jakub Jelinek
2007-11-08 2:20 ` Diego Novillo
2007-11-08 10:45 ` Richard Guenther
2007-11-13 16:30 ` Diego Novillo
2007-11-13 16:47 ` Richard Guenther
2007-11-14 12:36 ` Richard Guenther
2007-11-14 12:41 ` Richard Guenther
2007-11-14 13:01 ` Diego Novillo
2007-11-14 13:18 ` Richard Guenther
2007-11-14 13:59 ` Diego Novillo
2007-11-14 14:07 ` Richard Guenther [this message]
2007-11-14 14:09 ` Diego Novillo
2007-11-14 14:22 ` Richard Guenther
2007-11-14 15:29 ` Richard Guenther
2007-11-14 15:30 ` Diego Novillo
2007-11-15 13:55 ` Richard Guenther
2007-11-15 15:47 ` Richard Guenther
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=84fc9c000711140446l74fc9b36l4bfc2f024a21a66f@mail.gmail.com \
--to=richard.guenther@gmail.com \
--cc=dnovillo@google.com \
--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).