search for: r256003

...> lazy-loaders. > That is D16440. It reduces the metadata imported into the dest module (not sure whether that falls into (b) or just (c)). It could actually help full LTO as well since I also added support for not linking in unneeded DISubprogram for full LTO at the same time as ThinLTO in r256003. But right now the changes in the patch are guarded so they only happen under ThinLTO since some of the other things we prune from the imported DICompileUnit only applies to ThinLTO. I could restructure that a bit to get the reduced retained types importing to occur for full LTO as well. > I h...

...rs. > > That is D16440. It reduces the metadata imported into the dest module (not sure whether that falls into (b) or just (c)). > > It could actually help full LTO as well since I also added support for not linking in unneeded DISubprogram for full LTO at the same time as ThinLTO in r256003. But right now the changes in the patch are guarded so they only happen under ThinLTO since some of the other things we prune from the imported DICompileUnit only applies to ThinLTO. I could restructure that a bit to get the reduced retained types importing to occur for full LTO as well. > >...

...16440. It reduces the metadata imported into the dest module > (not sure whether that falls into (b) or just (c)). > > > > It could actually help full LTO as well since I also added support for > not linking in unneeded DISubprogram for full LTO at the same time as > ThinLTO in r256003. But right now the changes in the patch are guarded so > they only happen under ThinLTO since some of the other things we prune from > the imported DICompileUnit only applies to ThinLTO. I could restructure > that a bit to get the reduced retained types importing to occur for full > LTO...

...> That is D16440. It reduces the metadata imported into the dest module (not sure whether that falls into (b) or just (c)). > > > > It could actually help full LTO as well since I also added support for not linking in unneeded DISubprogram for full LTO at the same time as ThinLTO in r256003. But right now the changes in the patch are guarded so they only happen under ThinLTO since some of the other things we prune from the imported DICompileUnit only applies to ThinLTO. I could restructure that a bit to get the reduced retained types importing to occur for full LTO as well. > >...

I have some ideas to allow the BitcodeReader to lazy-load debug info metadata, and wanted to air this on llvm-dev before getting too deep into the code. Motivation ========== Based on some analysis Mehdi ran (ping him for details), there are three (related) compile-time bottlenecks we're seeing with `-flto=thin -g`: a) Reading the large number of Metadata bitcode records in the global