[LLVMdev] PassManager again...

Andreas Neustifter astifter-llvm at gmx.at
Thu Dec 3 07:56:36 PST 2009


Hi all!

On 11/20/2009 06:29 PM, Devang Patel wrote:
 >
> On Fri, Nov 20, 2009 at 6:54 AM, Andreas Neustifter  wrote:
>>
>> If I use  AU.addRequired<ProfileInfo>() in SelectionDAGISel.cpp the
>> wrong ProfileInfo is used. It uses the "No ProfileInfo" implementation
>> if ProfileInfo but not the one from ProfileInfoLoaderPass. (Which is
>> immediately discarded after creation.)
>>
>
> You need to debug pass manager yourself in a debugger to understand
> why pass manager is discarding ProfileInfoLoaderPass. Usually it is
> because
>
> 1) The pass manager does not know of any user of your pass - If that's
> not the case then find out why? This may be a bug.
> 2) Someone is not preserving this pass. If that's the case then who is
> it? Is it explicitly claiming to preserve your pass ?

Okay, got it, did cost me 4 days of debugging tough.

Why so long? PassManager is quite ingeniosly crafted, making it hard to
debug. Thats why there is massive CLI-Support for debugging passes 
(think "-debug-pass=Details"). Problem is that the debug output does not 
show _all_ the passes that are invalidated but some _only some_ of them.

Since _some_ invalidated passes are show, I never bothered to to check 
if my Pass was _actually really_ preserved because it did not show up in
the list of invalidated passes.

Attached patch adds debug output for _all_ invalidated passes. I will
commit this in the next days if there are no objections.

On 11/20/2009 04:30 PM, Anton Korobeynikov wrote:
 >
 > Andreas Neustifter wrote:
 >>
 >> When I use AU.addRequiredID(ProfileLoaderPassID) I get assertions
 >> that a normal constructor is not available. Interesting enough its
 >> not the ProfileInfoLoader constructor thats misssing but the one from
 >> MachineFunctionAnalysis, which indeed has none.
 >
 > Right. You cannot schedule any pass IR-level pass after
 > MachineFunctionAnalysis. I have no idea whether this is intentional or
 > not.

I found out about that one too. As mentioned in MachineFunctionPass.h:42 
a MachineFunctionPass that overrides getAnalysisUsage() _has_ to call 
MachineFunctionPass::getAnalysisUsage() because there 
MachineFunctionAnalysis is required and preserved.

The problem mentioned by me was in a newly created 
BranchFolderPass::getAnalysisUsage() method which did not call 
MachineFunctionPass::getAnalysisUsage().

Andi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-r90454.passmanager.patch
Type: text/x-diff
Size: 801 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091203/59f0eb99/attachment.patch>


More information about the llvm-dev mailing list