[LTO] Make Move lto-symtab.c out of lto/

[LTO] Make Move lto-symtab.c out of lto/

[Doug Kwan (關振德)]

Rafael,

     I have a sandbox for making ipa-cp.c WHOPR friend but I ran into
problem as some of the lto_symtab functions are used indirectly and I
got linker errors in the C/C++ FEs because the lto_symbtab functions
are into the lto1 FE only.  Although we do not read IR files in
non-lto FEs, the IR reading functions are present in all FEs due to
pointers to them from the ipa_opt_pass structs.   The summary readers
now need to know about symbol resolution to discard or ignore summary
information.  For example, you had to extract a part of the
lto-cgraph.c into lto1 because it needs to use
lto_symtab_prevailing_decl.   You also defined a lang-hook just for
input_cgraph.  I don't think we should define other lang-hooks for
other IPA summary readers.  Instead the lto_symtab functions should be
visibile to all FEs. This can simply be done by pulling the file
lto-symtab.c out of lto1.  When that it done.  I think we can
eliminate the input_cgraph hook and move back the code to
lto-cgraph.c, where it logically belongs.

Thoughts? Comments?

-Doug

Re: [LTO] Make Move lto-symtab.c out of lto/

[Rafael Espindola]

2008/10/24 Doug Kwan (關振德) <dougkwan@google.com>:
> Rafael,
>
>     I have a sandbox for making ipa-cp.c WHOPR friend but I ran into
> problem as some of the lto_symtab functions are used indirectly and I
> got linker errors in the C/C++ FEs because the lto_symbtab functions
> are into the lto1 FE only.  Although we do not read IR files in
> non-lto FEs, the IR reading functions are present in all FEs due to
> pointers to them from the ipa_opt_pass structs.   The summary readers
> now need to know about symbol resolution to discard or ignore summary
> information.  For example, you had to extract a part of the
> lto-cgraph.c into lto1 because it needs to use
> lto_symtab_prevailing_decl.   You also defined a lang-hook just for
> input_cgraph.  I don't think we should define other lang-hooks for
> other IPA summary readers.  Instead the lto_symtab functions should be
> visibile to all FEs. This can simply be done by pulling the file
> lto-symtab.c out of lto1.  When that it done.  I think we can
> eliminate the input_cgraph hook and move back the code to
> lto-cgraph.c, where it logically belongs.
>
> Thoughts? Comments?

Go for it :-)

I didn't like the addition of the langhook, but it was the easy path.
I don't think it will scale nicely.

The best solution would to have a libgimple that would contain and
isolate the code to read and write IL and call graph, but it will be a
long time before we have one (it is hopeless to have anything but gcc
understand trees). Maybe it can be used as a decision tool. Anything
that would be in such a library should go in gcc/*. Symbol resolution
is in :-)

> -Doug
>


Thanks,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047

Antwort: Re: [LTO] Make Move lto-symtab.c out of lto/

[Markus Milleder]

Rafael Espindola schrieb am 24.10.2008 09:58:12:

> 2008/10/24 Doug Kwan (關振?) <dougkwan@google.com>:
> > Rafael,
> >
<snip>
> > other IPA summary readers.  Instead the lto_symtab functions should be
> > visibile to all FEs. This can simply be done by pulling the file
> > lto-symtab.c out of lto1.  When that it done.  I think we can
> > eliminate the input_cgraph hook and move back the code to
> > lto-cgraph.c, where it logically belongs.
> >
> > Thoughts? Comments?
>
> Go for it :-)
>
> I didn't like the addition of the langhook, but it was the easy path.
> I don't think it will scale nicely.
>
> The best solution would to have a libgimple that would contain and
> isolate the code to read and write IL and call graph, but it will be a
> long time before we have one (it is hopeless to have anything but gcc
> understand trees). Maybe it can be used as a decision tool. Anything
> that would be in such a library should go in gcc/*. Symbol resolution
> is in :-)
>
Would it be useful to start that library now as a directory of directly
used sources, with the intention to make it a real lib later ?
Ideally before merging LTO?

      Markus Milleder

Re: Re: [LTO] Make Move lto-symtab.c out of lto/

[Rafael Espindola]

> Would it be useful to start that library now as a directory of directly
> used sources, with the intention to make it a real lib later ?
> Ideally before merging LTO?

The problem is that trees have 3 uses: FE, ME types and values, and as
a hack during RTL expansion.  I think it would be better to start
writing a libgimple once it can work with gimple only :-)

>      Markus Milleder
>
>
>


Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047

Re: [LTO] Make Move lto-symtab.c out of lto/

[Doug Kwan (關振德)]

I tried but it seems that lto-symtab.c also depends on language
specific things in the lto1 FE.  Basically we store symbol resolution
in identifier nodes, so we use an lto1 identifier instead of the
regular one.  Do we have hash tables with weak references?

So for the time being, I replace lto-cgraph lang-hook with a symtab
access lang-hook.  A number of symtab operations are now exported
through that hook.

-Doug

2008/10/24 Rafael Espindola <espindola@google.com>:
> 2008/10/24 Doug Kwan (關振德) <dougkwan@google.com>:
>> Rafael,
>>
>>     I have a sandbox for making ipa-cp.c WHOPR friend but I ran into
>> problem as some of the lto_symtab functions are used indirectly and I
>> got linker errors in the C/C++ FEs because the lto_symbtab functions
>> are into the lto1 FE only.  Although we do not read IR files in
>> non-lto FEs, the IR reading functions are present in all FEs due to
>> pointers to them from the ipa_opt_pass structs.   The summary readers
>> now need to know about symbol resolution to discard or ignore summary
>> information.  For example, you had to extract a part of the
>> lto-cgraph.c into lto1 because it needs to use
>> lto_symtab_prevailing_decl.   You also defined a lang-hook just for
>> input_cgraph.  I don't think we should define other lang-hooks for
>> other IPA summary readers.  Instead the lto_symtab functions should be
>> visibile to all FEs. This can simply be done by pulling the file
>> lto-symtab.c out of lto1.  When that it done.  I think we can
>> eliminate the input_cgraph hook and move back the code to
>> lto-cgraph.c, where it logically belongs.
>>
>> Thoughts? Comments?
>
> Go for it :-)
>
> I didn't like the addition of the langhook, but it was the easy path.
> I don't think it will scale nicely.
>
> The best solution would to have a libgimple that would contain and
> isolate the code to read and write IL and call graph, but it will be a
> long time before we have one (it is hopeless to have anything but gcc
> understand trees). Maybe it can be used as a decision tool. Anything
> that would be in such a library should go in gcc/*. Symbol resolution
> is in :-)
>
>> -Doug
>>
>
>
> Thanks,
> --
> Rafael Avila de Espindola
>
> Google | Gordon House | Barrow Street | Dublin 4 | Ireland
> Registered in Dublin, Ireland | Registration Number: 368047
>

Re: [LTO] Make Move lto-symtab.c out of lto/

[Tom Tromey]

>>>>> "Doug" == "Doug Kwan (關振德)" <dougkwan@google.com> writes:

Doug> Do we have hash tables with weak references?

Yes, see the GTY if_marked attribute.

Tom

Re: [LTO] Make Move lto-symtab.c out of lto/

[Diego Novillo]

2008/10/24 Doug Kwan (關振德) <dougkwan@google.com>:
> I tried but it seems that lto-symtab.c also depends on language
> specific things in the lto1 FE.  Basically we store symbol resolution
> in identifier nodes, so we use an lto1 identifier instead of the
> regular one.

How about having a symbol table indexed by DECL_UID and storing symbol
resolution in that table?  In fact, data_in.globals_index could be our
symbol table.

Diego.