[LLVMdev] PassManager again...
astifter-llvm at gmx.at
Thu Dec 3 07:56:36 PST 2009
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
> 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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: not available
More information about the llvm-dev