This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [LTO] Make Move lto-symtab.c out of lto/
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 (Ãö®¶¼w) <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
>