[llvm-dev] pass invalidation

Sun Jun 19 19:25:39 PDT 2016

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>