[PATCH] D55309: ThinLTO: Do not import debug info for imported global constants

[Teresa Johnson via Phabricator via llvm-commits]

tejohnson added a comment.

In D55309#1320360 <https://reviews.llvm.org/D55309#1320360>, @dblaikie wrote:

> In D55309#1320279 <https://reviews.llvm.org/D55309#1320279>, @evgeny777 wrote:
>
> >
>


I can answer some of these questions.

>>> Could you tell me the commands I need to run to test this?
>> 
>> You can try:
>> 
>>   clang -flto=thin -O3 main.c foo.c -fuse-ld=lld

Use -Wl,-save-temps to get bitcode after various ThinLTO phases and the final object files. You probably want to first do clang -c then a separate step to link the .o files to get more meaningful names of these intermediate files.

>>   
> 
> I'll give that a go when I get to my desk in an hour or so.
> 
> In the mean time perhaps you can help me understand some of the corner cases:
> 
> - Can this happen multiple times for a single variable? (It be imported and internalized into multiple other modules)

Yes

> - Does this alter the original variable in the original modules at all? Or does it remain untouched/external linkage?

It will also be internalized.

> - In the above example, how does llvm know there won't be other uses of the variable outside the scope of this compilation command, that might modify the value of the variable? (Where does it decide "main is the only entry point"?)

The thin link is driven off of linker symbol resolution info.

> 
> 
>>> I'm investigating/trying to address significant regressions in object size, executable size, dwp size, symbolizing performance Caused by this change in thinlto debug info.
>> 
>> After some thinking I lean towards reverting my change in IRMover. Most of imported variables will be const-folded by optimizer, so debug info will be a waste of disk space.
> 
> Debug info for global constants is still useful, so if this resulted in no description of the global variable, that could be unfortunate - but might be a useful stop-gap to fix the growth regression and then I can help you fix the debug info loss if there is one. But I wouldn't mind understanding that trade-off before we make it




Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55309/new/

https://reviews.llvm.org/D55309