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

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Dec 5 09:36:20 PST 2018


dblaikie added a comment.

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

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


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)
- Does this alter the original variable in the original modules at all? Or does it remain untouched/external linkage?
- 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"?)

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





More information about the llvm-commits mailing list