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>