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

[Evan Cheng]

On Nov 13, 2012, at 5:42 PM, Owen Anderson <resistor at mac.com> wrote:

> On Nov 13, 2012, at 5:22 PM, Eric Christopher <echristo at gmail.com> wrote:
> 
>> 
>> 
>> 
>> On Tue, Nov 13, 2012 at 5:15 PM, Owen Anderson <resistor at mac.com> wrote:
>>> 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.
>> 
>> The use case I described was the one that you're talking about now - i.e. multiple modules as a single "compilation unit" with shared information between each additional compilation. I have no disagreement that this might be a desirable case for one off functions that share data among them (or can use some mangling to make it unique per additional module), but I was wondering if that's the plan or if there's something else? That a module is a single compilation unit is an invariant in the IR and passes as far as I can tell and it sounds like you'd be making the module passes change that? I'm not raising any objections really, just verifying that what it sounds like you're doing is what you're actually doing and what kind of complexity we're looking at in the setup and teardown/reset of an individual module pass.
> 
> I don't understand what you're saying here.  We definitely do NOT want to consider multiple modules as part of a single translation unit.  It's a significant element of our use case that the modules should be entirely distinct.

Yes, the modules are distinct and unconnected in any way. 

Evan

> 
> All we're trying to do here is save the setup time for constructing a PassManager (slow because it has to plan the pass pipeline) in a process that is going to compile many translation units during the process' lifetime.
> 
> -Owen
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121113/238a4618/attachment.html>