On 6/19/16 4:28 AM, Mehdi Amini via llvm-dev wrote:> >> On Jun 18, 2016, at 10:44 PM, Yuxi Chen via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi All, >> >> When I use llvm, I encounter a problem like "unable to schedule pass >> A required by C" >> I investigated deeper. It's like: >> I have three passes, say A, B, C(all are on function level) >> A would modify IR code. (change instruction order) >> >> For pass B, >> I would use the result of pass A, I use addRequired<B>(), and >> &getAnalysis<B>(), it works. >> >> void getAnalysisUsage(AU){ >> AU.addRequired<A>(); >> } >> >> >> For pass C, it will use the results of pass A and B. >> I use the way as used for pass B, but it failed, even for LoopInfo >> analysis pass(which is the built-in analysis pass). >> void getAnalysisUsage(AU){ >> AU.addRequired<A>(); >> AU.addRequired<B>(); >> } >> >> >> It seems because A would modify IR code, so for pass C, I need first >> load pass A then pass B, otherwise it will be invalidated. >> However, when I change the using order, I still got error "unable to >> schedule pass A required by C". >> >> Does anyone encounter the same problem before and have a solution? >> Any help is appreciated. > > Depending on other transformations isn’t recommended, and isn’t > supported by the soon-new-passmanager I believe. > The expectation is that the passes are added in order to the pass > manager by the client.Depending on transformation passes isn't supported by the legacy PassManager, either. Occasionally some passes can get away with it, but it often results in unschedule-able pass pipelines as above. If your transform pass does something to the code, other passes should either infer what it did by examining the IR. the IR contains the definitive information about the program (because it is the program). Alternatively, you could create an analysis pass upon which both your transform and analysis passes depend. The transform pass would update this new analysis pass with information on what it transformed; your later analysis passes could then query this information. This approach is fragile, but it could work. Regards, John Criswell> > In you case, I expect that it would “work” by removing the dependency > from C to A. If C requires B and B requires A, by scheduling C you’ll > get A, B, C in sequence. > > — > Mehdi > > > >> >> Best, >> Yuxi >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- John Criswell Assistant Professor Department of Computer Science, University of Rochester http://www.cs.rochester.edu/u/criswell -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160619/4d4e8fa1/attachment.html>
> On Jun 19, 2016, at 8:05 AM, John Criswell <jtcriswel at gmail.com> wrote: > > On 6/19/16 4:28 AM, Mehdi Amini via llvm-dev wrote: >> >>> On Jun 18, 2016, at 10:44 PM, Yuxi Chen via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>> >>> Hi All, >>> >>> When I use llvm, I encounter a problem like "unable to schedule pass A required by C" >>> I investigated deeper. It's like: >>> I have three passes, say A, B, C(all are on function level) >>> A would modify IR code. (change instruction order) >>> >>> For pass B, >>> I would use the result of pass A, I use addRequired<B>(), and &getAnalysis<B>(), it works. >>> >>> void getAnalysisUsage(AU){ >>> AU.addRequired<A>(); >>> } >>> >>> >>> For pass C, it will use the results of pass A and B. >>> I use the way as used for pass B, but it failed, even for LoopInfo analysis pass(which is the built-in analysis pass). >>> void getAnalysisUsage(AU){ >>> AU.addRequired<A>(); >>> AU.addRequired<B>(); >>> } >>> >>> >>> It seems because A would modify IR code, so for pass C, I need first load pass A then pass B, otherwise it will be invalidated. >>> However, when I change the using order, I still got error "unable to schedule pass A required by C". >>> >>> Does anyone encounter the same problem before and have a solution? >>> Any help is appreciated. >> >> Depending on other transformations isn’t recommended, and isn’t supported by the soon-new-passmanager I believe. >> The expectation is that the passes are added in order to the pass manager by the client. > > Depending on transformation passes isn't supported by the legacy PassManager, either.Really? What about LCSSA for example? My impression was that the legacy PM does not make any distinction between transformations and analysis. -- Mehdi> Occasionally some passes can get away with it, but it often results in unschedule-able pass pipelines as above. > > If your transform pass does something to the code, other passes should either infer what it did by examining the IR. the IR contains the definitive information about the program (because it is the program). > > Alternatively, you could create an analysis pass upon which both your transform and analysis passes depend. The transform pass would update this new analysis pass with information on what it transformed; your later analysis passes could then query this information. This approach is fragile, but it could work. > > Regards, > > John Criswell > >> >> In you case, I expect that it would “work” by removing the dependency from C to A. If C requires B and B requires A, by scheduling C you’ll get A, B, C in sequence. >> >> — >> Mehdi >> >> >> >>> >>> Best, >>> Yuxi >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > > > -- > John Criswell > Assistant Professor > Department of Computer Science, University of Rochester > http://www.cs.rochester.edu/u/criswell <http://www.cs.rochester.edu/u/criswell>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160619/b222398f/attachment.html>
On 6/19/16 12:36 PM, Mehdi Amini wrote:> >> On Jun 19, 2016, at 8:05 AM, John Criswell <jtcriswel at gmail.com >> <mailto:jtcriswel at gmail.com>> wrote: >> >> On 6/19/16 4:28 AM, Mehdi Amini via llvm-dev wrote: >>> >>>> On Jun 18, 2016, at 10:44 PM, Yuxi Chen via llvm-dev >>>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>>> >>>> Hi All, >>>> >>>> When I use llvm, I encounter a problem like "unable to schedule >>>> pass A required by C" >>>> I investigated deeper. It's like: >>>> I have three passes, say A, B, C(all are on function level) >>>> A would modify IR code. (change instruction order) >>>> >>>> For pass B, >>>> I would use the result of pass A, I use addRequired<B>(), and >>>> &getAnalysis<B>(), it works. >>>> >>>> void getAnalysisUsage(AU){ >>>> AU.addRequired<A>(); >>>> } >>>> >>>> >>>> For pass C, it will use the results of pass A and B. >>>> I use the way as used for pass B, but it failed, even for LoopInfo >>>> analysis pass(which is the built-in analysis pass). >>>> void getAnalysisUsage(AU){ >>>> AU.addRequired<A>(); >>>> AU.addRequired<B>(); >>>> } >>>> >>>> >>>> It seems because A would modify IR code, so for pass C, I need >>>> first load pass A then pass B, otherwise it will be invalidated. >>>> However, when I change the using order, I still got error "unable >>>> to schedule pass A required by C". >>>> >>>> Does anyone encounter the same problem before and have a solution? >>>> Any help is appreciated. >>> >>> Depending on other transformations isn’t recommended, and isn’t >>> supported by the soon-new-passmanager I believe. >>> The expectation is that the passes are added in order to the pass >>> manager by the client. >> >> Depending on transformation passes isn't supported by the legacy >> PassManager, either. > > Really? What about LCSSA for example? My impression was that the > legacy PM does not make any distinction between transformations and > analysis.The legacy PassManager doesn't make distinctions between analysis and transform passes per se. A pass is a pass; analysis passes are just passes that never modify the IR whereas transform passes are passes that may modify the IR. Since LLVM 2.0, the PassManager did not support the feature of using getAnalysisUsage<>() to dictate which transform passes were required to be run before a given pass. While one could write a pass that could act as both a transform pass and analysis pass, the PassManager didn't guarantee that it could schedule such passes (I believe primarily due to impossible-to-schedule pass schedules). I was told that the PassManager was really designed so that getAnalysisUsage<>() would specify analysis passes; whoever set up the pass pipeline was responsible for ensuring that prerequisite transforms were run when they needed to be run. Now, while the "do not schedule transform passes using getAnalysisUsage<>()" rule has been presented on the mailing list multiple times over the years, there are passes in LLVM that break it. I believe some passes require UnifyExitNodes. If you say LCSSA does, I'd believe it. However, in most cases, you don't need this feature, and breaking the rule can generate difficult-to-debug messages from the PassManager. Therefore, while the rule isn't followed all the time, I tell people who run into the problem not to require transform passes. Historically, debugging bad pass pipelines has been no fun, and it's terribly difficult for new LLVM users. Regards, John Criswell> > -- > Mehdi > >> Occasionally some passes can get away with it, but it often results >> in unschedule-able pass pipelines as above. >> >> If your transform pass does something to the code, other passes >> should either infer what it did by examining the IR. the IR contains >> the definitive information about the program (because it is the program). >> >> Alternatively, you could create an analysis pass upon which both your >> transform and analysis passes depend. The transform pass would >> update this new analysis pass with information on what it >> transformed; your later analysis passes could then query this >> information. This approach is fragile, but it could work. >> >> Regards, >> >> John Criswell >> >>> >>> In you case, I expect that it would “work” by removing the >>> dependency from C to A. If C requires B and B requires A, by >>> scheduling C you’ll get A, B, C in sequence. >>> >>> — >>> Mehdi >>> >>> >>> >>>> >>>> Best, >>>> Yuxi >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> -- >> John Criswell >> Assistant Professor >> Department of Computer Science, University of Rochester >> http://www.cs.rochester.edu/u/criswell >-- John Criswell Assistant Professor Department of Computer Science, University of Rochester http://www.cs.rochester.edu/u/criswell -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160619/e51d4b4d/attachment.html>
Hi,
Thanks for your reply.
But I still don't know how a transform pass updates a new analysis pass
after it modifies the IR. Can you explain it clearly? I am not familiar with
pass management and invocation.
Best,
Yuxi
________________________________
From: John Criswell [jtcriswel at gmail.com]
Sent: Sunday, June 19, 2016 10:05 AM
To: Mehdi Amini; Yuxi Chen
Cc: llvm-dev at lists.llvm.org; llvmdev-bounces at cs.uiuc.edu; llvmdev at
cs.uiuc.edu
Subject: Re: [llvm-dev] pass invalidation
On 6/19/16 4:28 AM, Mehdi Amini via llvm-dev wrote:
On Jun 18, 2016, at 10:44 PM, Yuxi Chen via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Hi All,
When I use llvm, I encounter a problem like "unable to schedule pass A
required by C"
I investigated deeper. It's like:
I have three passes, say A, B, C(all are on function level)
A would modify IR code. (change instruction order)
For pass B,
I would use the result of pass A, I use addRequired<B>(), and
&getAnalysis<B>(), it works.
void getAnalysisUsage(AU){
AU.addRequired<A>();
}
For pass C, it will use the results of pass A and B.
I use the way as used for pass B, but it failed, even for LoopInfo analysis
pass(which is the built-in analysis pass).
void getAnalysisUsage(AU){
AU.addRequired<A>();
AU.addRequired<B>();
}
It seems because A would modify IR code, so for pass C, I need first load pass A
then pass B, otherwise it will be invalidated.
However, when I change the using order, I still got error "unable to
schedule pass A required by C".
Does anyone encounter the same problem before and have a solution?
Any help is appreciated.
Depending on other transformations isn’t recommended, and isn’t supported by the
soon-new-passmanager I believe.
The expectation is that the passes are added in order to the pass manager by the
client.
Depending on transformation passes isn't supported by the legacy
PassManager, either. Occasionally some passes can get away with it, but it
often results in unschedule-able pass pipelines as above.
If your transform pass does something to the code, other passes should either
infer what it did by examining the IR. the IR contains the definitive
information about the program (because it is the program).
Alternatively, you could create an analysis pass upon which both your transform
and analysis passes depend. The transform pass would update this new analysis
pass with information on what it transformed; your later analysis passes could
then query this information. This approach is fragile, but it could work.
Regards,
John Criswell
In you case, I expect that it would “work” by removing the dependency from C to
A. If C requires B and B requires A, by scheduling C you’ll get A, B, C in
sequence.
—
Mehdi
Best,
Yuxi
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
--
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
http://www.cs.rochester.edu/u/criswell
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160620/0a4f1693/attachment.html>
On 6/20/16 3:46 PM, Yuxi Chen wrote:> Hi, > > Thanks for your reply. > But I still don't know how a transform pass updates a new analysis > pass after it modifies the IR. Can you explain it clearly? I am not > familiar with pass management and invocation.Passes can have methods that allow their internal state to be updated by other passes (the same way that their state can be queried by other passes). For example, the alias analysis passes have methods for querying alias information as well as methods that allow other passes to update the aliasing information when they make changes to the IR (so that friendly optimization passes don't invalidate alias analysis information when they make simple changes). Right now, your transform pass has a method which your other passes are using to query information (I am guessing that your transform pass is recording information on what it has done). I am suggesting that you create a new pass (call it "RK" for "Record Keeper") that implements this method (call it getInfo()). Additionally, the RK pass also implements a method called setInfo() which the transform pass uses to record any information that later passes will need. In their getAnalysisUsage<>() method, your passes preserve the results of the RK pass. In this way, your transform pass modifies the IR and dumps any information needed by your analysis passes into the RK pass. The RK pass does not modify the IR, so it doesn't create an impossible-to-schedule pass pipeline like your transform pass does. If this isn't clear, please let me know. I see that you're from UChicago, so I'm guessing that you need this for a research project. Regards, John Criswell> > Best, > Yuxi > ------------------------------------------------------------------------ > *From:* John Criswell [jtcriswel at gmail.com] > *Sent:* Sunday, June 19, 2016 10:05 AM > *To:* Mehdi Amini; Yuxi Chen > *Cc:* llvm-dev at lists.llvm.org; llvmdev-bounces at cs.uiuc.edu; > llvmdev at cs.uiuc.edu > *Subject:* Re: [llvm-dev] pass invalidation > > On 6/19/16 4:28 AM, Mehdi Amini via llvm-dev wrote: >> >>> On Jun 18, 2016, at 10:44 PM, Yuxi Chen via llvm-dev >>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>> >>> Hi All, >>> >>> When I use llvm, I encounter a problem like "unable to schedule pass >>> A required by C" >>> I investigated deeper. It's like: >>> I have three passes, say A, B, C(all are on function level) >>> A would modify IR code. (change instruction order) >>> >>> For pass B, >>> I would use the result of pass A, I use addRequired<B>(), and >>> &getAnalysis<B>(), it works. >>> >>> void getAnalysisUsage(AU){ >>> AU.addRequired<A>(); >>> } >>> >>> >>> For pass C, it will use the results of pass A and B. >>> I use the way as used for pass B, but it failed, even for LoopInfo >>> analysis pass(which is the built-in analysis pass). >>> void getAnalysisUsage(AU){ >>> AU.addRequired<A>(); >>> AU.addRequired<B>(); >>> } >>> >>> >>> It seems because A would modify IR code, so for pass C, I need first >>> load pass A then pass B, otherwise it will be invalidated. >>> However, when I change the using order, I still got error "unable to >>> schedule pass A required by C". >>> >>> Does anyone encounter the same problem before and have a solution? >>> Any help is appreciated. >> >> Depending on other transformations isn’t recommended, and isn’t >> supported by the soon-new-passmanager I believe. >> The expectation is that the passes are added in order to the pass >> manager by the client. > > Depending on transformation passes isn't supported by the legacy > PassManager, either. Occasionally some passes can get away with it, > but it often results in unschedule-able pass pipelines as above. > > If your transform pass does something to the code, other passes should > either infer what it did by examining the IR. the IR contains the > definitive information about the program (because it is the program). > > Alternatively, you could create an analysis pass upon which both your > transform and analysis passes depend. The transform pass would update > this new analysis pass with information on what it transformed; your > later analysis passes could then query this information. This > approach is fragile, but it could work. > > Regards, > > John Criswell > >> >> In you case, I expect that it would “work” by removing the dependency >> from C to A. If C requires B and B requires A, by scheduling C you’ll >> get A, B, C in sequence. >> >> — >> Mehdi >> >> >> >>> >>> Best, >>> Yuxi >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > -- > John Criswell > Assistant Professor > Department of Computer Science, University of Rochester > http://www.cs.rochester.edu/u/criswell-- John Criswell Assistant Professor Department of Computer Science, University of Rochester http://www.cs.rochester.edu/u/criswell -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160621/775f211c/attachment.html>