This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [lto] function to DECL associations for WPA repackaging


On Fri, Jun 13, 2008 at 12:49 AM, Daniel Berlin <dberlin@dberlin.org> wrote:
> On Thu, Jun 12, 2008 at 4:39 PM, Diego Novillo <dnovillo@google.com> wrote:
>> On 2008-06-12, Kenneth Zadeck <zadeck@naturalbridge.com> wrote:
>>
>>>  I have no idea how to make sure, in whopr, that function x sees foobar if
>>> you are going to cherry pick the globals also.
>>
>> I'm not sure I see the problem that you are pointing to.  In this program:
>>
>> int N;
>> int foobar;
>> int *bar = &foobar;
>> int **foo = &bar;
>> x ()
>> {
>>  int **x = foo;
>>  return **x;
>> }
>>
>> All of 'foobar', 'bar' and 'foo' will be in the list of symbols
>> referenced by x().
>
> Why do you think foobar will be in the list?
>
> (I'm just curious, i'm not saying you are wrong).

Citing the code (add_referenced_var):

      /* Scan DECL_INITIAL for pointer variables as they may contain
         address arithmetic referencing the address of other
         variables.
         Even non-constant initializers need to be walked, because
         IPA passes might prove that their are invariant later on.  */
      if (DECL_INITIAL (var)
          /* Initializers of external variables are not useful to the
             optimizers.  */
          && !DECL_EXTERNAL (var))
        walk_tree (&DECL_INITIAL (var), find_vars_r, NULL, 0);

It is because foo might turn out to be const (ipa-reference), ccp would
then pull in bar from its DECL_INITIAL and subsequently foobar
is referenced from its DECL_INITIAL (which you then can pull in as well).

We add all these reachable through DECL_INITIAL vars to avoid needing
to add them to referenced vars later on demand (I have a patch for that)
and to avoid aliasing issues (I don't have a patch for this part -- basically
we'd need to re-compute alias information if a pass added globals or
addressable variables to referenced vars.  We can do this via a global
flag and a TODO).

In the end we need to fix this anyway, as you can for example see in
PR36291 where we basically end up with every global in every
functions referenced vars and

 tree find ref. vars   :  15.36 ( 5%) usr   0.80 ( 8%) sys  15.90 ( 5%) wall
817801 kB (35%) ggc

referenced vars computation is really inefficient here - quadratic in
the number of functions and globals.  We could fix that particular
part by keeping a bitmap of referenced vars per global variable and
just merging that in.  But probably pulling them in on-demand is
a more practical approach (after all this huge number of vars is
also the cause of the slowness of alias computation and partitioning
in this testcase).

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]