David Blaikie e204899c29 ThinLTO: Don't import aliases of any kind (even linkonce_odr) ... Summary: Until a more advanced version of importing can be implemented for aliases (one that imports an alias as an available_externally definition of the aliasee), skip the narrow subset of cases that was possible but came at a cost: aliases of linkonce_odr functions could be imported because the linkonce_odr function could be safely duplicated from the source module. This came/comes at the cost of not being able to 'home' imported linkonce functions (they had to be emitted linkonce_odr in all the destination modules (even if they weren't used by an alias) rather than as available_externally - causing extra object size). Tangentially, this also was the only reason ThinLTO would emit multiple CUs in to the resulting DWARF - which happens to be a problem for Fission (there's a fix for this in GDB but not released yet, etc). (actually it's not the only reason - but I'm sending a patch to fix the other reason shortly) There's no reason to believe this particularly narrow alias importing was especially/meaningfully important, only that it was /possible/ to implement in this way. When a more general solution is done, it should still satisfy the DWARF concerns above, since the import will still be available_externally, and thus not create extra CUs. Since now all aliases are treated the same, I removed/simplified some test cases since they were testing corner cases where there are no longer any corners. Reviewers: tejohnson, mehdi_amini Differential Revision: https://reviews.llvm.org/D35875 llvm-svn: 309278		2017-07-27 15:09:06 +00:00
..
Inputs	Revert "Restore with fix "[ThinLTO] Ensure we always select the same function copy to import""	2017-07-17 19:25:38 +00:00
adjustable_threshold.ll
funcimport_alias.ll
funcimport_debug.ll
funcimport.ll	ThinLTO: Don't import aliases of any kind (even linkonce_odr)	2017-07-27 15:09:06 +00:00
hotness_based_import2.ll
hotness_based_import.ll
inlineasm.ll