[PATCH] D16124: Add to the split module utility an SCC based method which allows not to globalize any local variables.

Tobias Edler von Koch via llvm-commits llvm-commits at lists.llvm.org
Tue Jan 12 15:38:31 PST 2016


tobiasvk added a subscriber: joker.eph.
tobiasvk added a comment.

In http://reviews.llvm.org/D16124#325170, @pcc wrote:

> As far as I can tell, it seems that in a typical LTO scenario with internalization, this partitioning would be strongly biased towards a single partition containing most of the code. Do you have a plan to address this?


That's correct. Locally, we remember which symbols were originally non-local and restore their linkage type just prior to splitting / CodeGen. Constant merging and similar optimizations also reduce the ability to partition which is a bigger issue (that I haven't got a great solution for yet). But as it is, this is just as much about correctness as it is about getting the 'best' split.

In http://reviews.llvm.org/D16124#325188, @joker.eph wrote:

> What is the issue with the current globalization? You mentioned that it "might not be desirable in some scenarios", can you elaborate?


Well, an obvious example would applying LTO to a library or to only part of your program. If locals become global, you may end up with name collisions or symbols you don't want to export.


http://reviews.llvm.org/D16124





More information about the llvm-commits mailing list