[llvm-commits] Patch, enable reusing a module pass manager across multiple modules

Owen Anderson resistor at mac.com
Tue Nov 13 17:15:27 PST 2012


On Nov 13, 2012, at 4:38 PM, Eric Christopher <echristo at gmail.com> wrote:

> 
> 
> 
> On Tue, Nov 13, 2012 at 4:28 PM, Owen Anderson <resistor at mac.com> wrote:
>> 
>> On Nov 13, 2012, at 4:17 PM, Eric Christopher <echristo at gmail.com> wrote:
>> 
>>> On Tue, Nov 13, 2012 at 4:05 PM, Pedro Artigas <partigas at apple.com> wrote:
>>>  
>>>> The idea is that we will compile many modules together and save compile time by reusing the module passes data structures.
>>> 
>>> Isn't this what we have llvm-link for (or the library equivalent)? This is why I asked the question.
>> 
>> The intended use case is for a JIT or other long-running compilation process, where we will compile many distinct modules that were not all available to be linked together at the same time.  If we can reuse the PassManager structure across multiple module compilations, we can save the compile time cost of setting up the PassManager on all but the first module.
> 
> With the (possible) assumption that all globals/functions/etc are going to be unique per additional module and not held over. Also how would this affect things like inlining or cross function optimization? In other words, are you going to just have the information and not the original module or are you going to keep a list of modules to the side and the passes remember in which module the code they care about resides?

The use case you describe where you want to append to an existing module can already be handled today.  Our intention is to support an additional use case, one where appending to the module is not desirable.  Imagine the case of a compile server which produces a distinct object file per client request, but still does not want to pay the cost to reinitialize the pass manager on each request.

-Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121113/75d6854c/attachment.html>


More information about the llvm-commits mailing list