[LLVMdev] LoopPass doFinalization() called multiple times per program?

Stephen McGruer stephen.mcgruer at gmail.com
Mon Dec 17 05:02:39 PST 2012


I see. In the meantime, is there a suggested method to do actual
finalization code (i.e. code that runs after *all* of the loops have been
processed)?

Thanks,
Stephen


On 17 December 2012 12:57, Duncan Sands <baldrick at free.fr> wrote:

> Hi Chandler,
>
>
> On 17/12/12 13:47, Chandler Carruth wrote:
>
>> On Sun, Dec 16, 2012 at 7:23 AM, Duncan Sands <baldrick at free.fr
>> <mailto:baldrick at free.fr>> wrote:
>>
>>     Hi Stephen,
>>
>>
>>     On 13/12/12 18:58, Stephen McGruer wrote:
>>
>>         I'm wondering if the documentation for LoopPass
>>         (http://llvm.org/docs/__**WritingAnLLVMPass.html#__**LoopPass<http://llvm.org/docs/__WritingAnLLVMPass.html#__LoopPass>
>>         <http://llvm.org/docs/**WritingAnLLVMPass.html#**LoopPass<http://llvm.org/docs/WritingAnLLVMPass.html#LoopPass>>)
>> is misleading or
>>
>>         incorrect (or if I'm just missing something.) The documentation
>> states:
>>
>>         "The doFinalization method ... is called when the pass framework
>> has
>>         finished
>>         calling runOnLoop
>>         <http://llvm.org/docs/__**WritingAnLLVMPass.html#__**runOnLoop<http://llvm.org/docs/__WritingAnLLVMPass.html#__runOnLoop>
>>
>>         <http://llvm.org/docs/**WritingAnLLVMPass.html#**runOnLoop<http://llvm.org/docs/WritingAnLLVMPass.html#runOnLoop>>>
>> for
>>
>>         every loop in the program being compiled."
>>
>>           From this, I understood that for a single instance of a LoopPass
>>         sub-class, the
>>         doFinalization method would be called exactly once, after all
>> loops had been
>>         seen. However in practice I am seeing doFinalization() being
>> called multiple
>>         times per program. Digging into the code, it appears that
>> LPPassManager
>>         actually
>>         makes the calls to doFinalization() at the end of it's
>> runOnFunction()
>>         method
>>         (http://llvm.org/docs/doxygen/**__html/LoopPass_8cpp_source.__**
>> html#l00281<http://llvm.org/docs/doxygen/__html/LoopPass_8cpp_source.__html#l00281>
>>         <http://llvm.org/docs/doxygen/**html/LoopPass_8cpp_source.**
>> html#l00281<http://llvm.org/docs/doxygen/html/LoopPass_8cpp_source.html#l00281>>,
>> at
>>
>>         time of
>>         writing). This therefore means that doFinalization() can be
>> called multiple
>>         times per LoopPass; as many as there are functions defined in the
>> input
>>         file.
>>
>>
>>     my understanding is that this is the expected behaviour and the
>> documentation
>>     should be improved (want to propose a patch?).
>>
>>
>> I'm actually really hoping to change this behavior in the not-too-distant
>> future.
>>
>> The goal that I and several others have worked out is that for *all*
>> passes, the
>> doInitialization and doFinalization are called once per module. All of the
>> doInitialization methods should be called before the first pass's runOn***
>>   method is called, and all of the doFinalization calls should be after
>> the last
>> pass's runOn*** have finished.
>>
>
> would it still be possible to optimize and codegen functions as they are
> output
> (rather than waiting for the module to be completely output before doing
> this)?
>
> Ciao, Duncan.
>
>
>> The goal of the initialization and finalization methods is to allow
>> per-module
>> caching, uniquing, setup, and teardown.
>>
>> I know that we are quite far from this goal in practice sadly, but I
>> think the
>> goal remains the same.
>>
>>
>>     Ciao, Duncan.
>>
>>
>>         Assuming I have made no mistakes here, is this a case of poorly
>> written
>>         documentation, or an error in the implementation? I note that
>>         FPPassManager does
>>         it calls to FunctionPass' doFinalization() in it's own
>> doFinalization()
>>         method,
>>         which seems the correct behaviour to me.
>>
>>         Thanks,
>>         Stephen
>>
>>
>>         ______________________________**___________________
>>         LLVM Developers mailing list
>>         LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>> http://llvm.cs.uiuc.edu
>>         http://lists.cs.uiuc.edu/__**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev>
>>         <http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>> >
>>
>>
>>     ______________________________**___________________
>>     LLVM Developers mailing list
>>     LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>> http://llvm.cs.uiuc.edu
>>     http://lists.cs.uiuc.edu/__**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev>
>>     <http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>> >
>>
>>
>>
> ______________________________**_________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121217/91cece81/attachment.html>


More information about the llvm-dev mailing list