public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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.

  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).