[llvm-dev] Regarding the project "Create LoopNestPass"
Ta-Wei Tu via llvm-dev
llvm-dev at lists.llvm.org
Fri Jul 24 03:08:20 PDT 2020
Hi,
I misunderstood what `addSiblingLoops()` does - the analogy should be
something like "addNewLoopNests()" which deals with the insertion of new
loop nests into the function. I will add this functionality into
`LNPMUpdater`.
Also, I just realized that some regression tests rely on the type names of
the passes, so `FunctionToLoopNestPassAdaptor` should be implemented
separately or the tests will have to be modified.
Sorry for the confusion.
Sincerely,
Ta-Wei, Tu
Ta-Wei Tu <tu.da.wei at gmail.com> 於 2020年7月24日 週五 下午1:27寫道：
> Hi,
>
> I would like to give a quick update on what my current design and
> implementation go like.
>
> Basically, the `FunctionToLoopPassAdaptor` is now modified to a generic
> version `FunctionToLoopUnitPassAdaptor`, which allows re-using the existing
> codes to implement `FunctionToLoopNestPassAdaptor`, with the help of
> additional metadata associated with `Loop` and `LoopNest`. Both
> `FunctionToLoopPassAdaptor` and `FunctionToLoopNestPassAdaptor` are aliases
> to `FunctionToLoopUnitPassAdaptor` and they operates on `Loop`, and the
> `FunctionToLoopNestPassAdaptor` will construct the `LoopNest` object lazily
> for the given `LoopNestPass` to run on.
>
> The `LNPMUpdater` only support `revisitCurrentLoopNest()` and
> `markLoopNestAsDeleted()` since other functionalities like
> `addChildLoops()` and `addSiblingLoops()` that `LPMUpdater` provide don't
> seem to be meaningful since we're dealing with outer-most `LoopNest`s.
> Still, an analogy of `addSiblingLoops()` can be implemented as something
> like `addAllLoopNests()`. What's your opinion on that?
>
> Currently, `LoopNestToLoopPassAdaptor` is also implemented to allow
> injecting a `LoopPassManager` into a `LoopNestPassManager`. The reason why
> I think this is useful is that both `LoopPass` and `LoopNestPass` requires
> loop canonicalization passes to be run first, and composing both of them
> and promoting them into a single `FunctionPass` can reduce unnecessary runs
> of the canonicalization phases. With these, the pipeline can be built like:
>
> ```
> FunctionPassManager FPM;
> LoopNestPassManager LNPM;
> LoopPassManager LPM;
> LNPM.addPass(SomeLoopNestPass());
> LPM.addPass(SomeLoopPass());
> LNPM.addPass(createLoopNestToLoopPassAdaptor(LPM));
> FPM.addPass(createFunctionToLoopNestPassAdaptor(LNPM));
>
> // This still works, but the loop canonicalization passes will be run
> twice:
> // FPM.addPass(createFunctionToLoopPassAdaptor(LPM));
> // FPM.addPass(createFunctionToLoopNestPassAdaptor(LNPM));
> ```
>
> `LoopNestAnalysisManager` and the proxies between `LoopAnalysis`,
> `LoopNestAnalysis` and `FunctionAnalysis` are also implemented.
> One of the problems now is on parsing the pipeline. In the current
> `PassBuilder`, a function pass is implicitly created and wrapping the
> subsequent loop passes. If we allow putting `LoopPass` into `LoopNestPass`
> in the future as described above, what would be a good way to distinguish
> whether we should choose "function - loopnest - loop" or "function - loop"
> in this case?
>
> As this is my first patch to LLVM, I would also like to ask what would
> generally be a good time to submit a patch like this. As most of the
> functionalities are completed but not tested, should I submit the patch as
> soon as all the existing tests pass and add tests specific to the
> `LoopNestPass` later so that people can provide feedback on the overall
> design first, or should I submit the patch after implementing fine-grained
> tests?
>
> What are your thoughts on the design? Thank you very much!
>
> Sincerely,
> Ta-Wei Tu
>
> Ettore Tiotto <etiotto at ca.ibm.com> 於 2020年7月21日 週二 下午8:43寫道：
>
>> > One question I have is whether the IRUnit LoopNestPass operates on
>> should be Loop or LoopNest, since I'm not quite sure about the usage of
>> LoopNest and why it should be constructed with a ScalarEvolution.
>>
>> That's a good point, we can make ScalarEvolution optional for LoopNest.
>> Currently, the only use case is to check if the loop nest is perfect, which
>> can provide a more conservative result if ScalarEvolution is not given.
>> Having said that, ScalarEvolution is one of the analyses in
>> LoopStandardAnalysisResults, so all LoopPasses already have access to
>> ScalarEvolution.
>> LoopNest provides some useful utilities, although it is still not at a
>> manual phrase.
>> My personal opinion is all the mechanism of the LoopNest, e.g. LoopNestPassManager,
>> LPMUpdater, etc, should operates on Loop. While IRUnitT which is used by
>> loop nest transformations/analyses should operates on LoopNest.
>> @etiotto What's your opinion on that?
>>
>> Determining whether a loop nest is perfect is a fundamental feature
>> for LoopNest analysis, and ScalarEvolution is required to catch not-trivial
>> cases. I agree that SE should be always available to a LoopNest pass. The
>> LoopNest analysis should be available to a LoopNest pass manager, and a
>> LoopNest pass IMO should operate on a LoopNest IR unit rather than a Loop.
>>
>> Ettore Tiotto
>> IBM Canada Laboratory, 8200 Warden Ave, Markham, ON L6G 1C7, Canada
>> etiotto at ca.ibm.com -- Phone: (905) 413-2387
>>
>> “No great discovery was ever made without a bold guess.” - Isaac Newton
>>
>>
>>
>> ----- Original message -----
>> From: Whitney T Tsang/Toronto/IBM
>> To: Ta-Wei Tu <tu.da.wei at gmail.com>
>> Cc: llvm-dev <llvm-dev at lists.llvm.org>, Whitney Tsang <
>> whitney.uwaterloo at gmail.com>, Ettore Tiotto/Toronto/IBM at IBMCA
>> Subject: Re: [EXTERNAL] Re: [llvm-dev] Regarding the project "Create
>> LoopNestPass"
>> Date: Sat, Jul 18, 2020 3:32 PM
>>
>> Hi Ta-Wei,
>>
>> > We might also need a LNPMUpdater (LoopNestPassManagerUpdater) which
>> disallows adding inner-loops back into the pipeline, and
>> LoopNestPassManager will simply be PassManager<Loop, LoopAnalysisManager,
>> LoopStandardAnalysisResult &, LNPMUpdater &>.
>>
>> LNPMUpdater should have some functionalities of LPMUpdater, e.g. adding
>> sibling loop nest, revisit the current loop nest, etc.
>>
>> > One question I have is whether the IRUnit LoopNestPass operates on
>> should be Loop or LoopNest, since I'm not quite sure about the usage of
>> LoopNest and why it should be constructed with a ScalarEvolution.
>>
>> That's a good point, we can make ScalarEvolution optional for LoopNest.
>> Currently, the only use case is to check if the loop nest is perfect, which
>> can provide a more conservative result if ScalarEvolution is not given.
>> Having said that, ScalarEvolution is one of the analyses in
>> LoopStandardAnalysisResults, so all LoopPasses already have access to
>> ScalarEvolution.
>> LoopNest provides some useful utilities, although it is still not at a
>> manual phrase.
>> My personal opinion is all the mechanism of the LoopNest, e.g. LoopNestPassManager,
>> LPMUpdater, etc, should operates on Loop. While IRUnitT which is used by
>> loop nest transformations/analyses should operates on LoopNest.
>> @etiotto What's your opinion on that?
>>
>> > Also, it is stated that "we want to create a LoopNestPass, where
>> transformations intended for loop nest can inherit from it" in the original
>> GSoC project description, but I believe that inheriting from a Pass
>> subclass is no longer required in the New Pass Manager. So should we also
>> implement a LoopNestPass subclass that allows implementing loop-nest-passes
>> for the Legacy Pass Manager?
>>
>> Right, the wording should be corrected. Given that the New Pass Manager
>> will soon be the default Pass Manager, we should not spend extra effort to
>> create LoopNestPass in Legacy Pass Manager.
>>
>> > Finally, I have some questions that might not be very relevant to the
>> project. But currently, how does the LegacyPassManager and the
>> NewPassManager interact? Also, is it possible to add passes designed for
>> LegacyPassManager into the NewPassManager and vice versa?
>>
>> Most transformations have both for LegacyPassManager and NewPassManager,
>> and have the actual implementation of the transformations in a separate
>> class, or a static function that can be call by both.
>> e.g. LoopFuseLegacy is for LegacyPassManager , *LoopFusePass*
>> <https://llvm.org/doxygen/classllvm_1_1LoopFusePass.html#a971f40ada3f1410759faede02bfbace7> is
>> for NewPassManager, and both create LoopFuser and do the transformation
>> there.
>>
>> Looking forward to your first patch!
>>
>> Regards,
>> Whitney Tsang
>>
>>
>> [image: Inactive hide details for Ta-Wei Tu ---2020/07/18 07:38:44
>> AM---Hi, Thanks for your help! I've checked the sources that you men]Ta-Wei
>> Tu ---2020/07/18 07:38:44 AM---Hi, Thanks for your help! I've checked the
>> sources that you mentioned.
>>
>> From: Ta-Wei Tu <tu.da.wei at gmail.com>
>> To: Whitney Tsang <whitney.uwaterloo at gmail.com>
>> Cc: llvm-dev <llvm-dev at lists.llvm.org>, whitneyt at ca.ibm.com
>> Date: 2020/07/18 07:38 AM
>> Subject: [EXTERNAL] Re: [llvm-dev] Regarding the project "Create
>> LoopNestPass"
>> ------------------------------
>>
>>
>>
>> Hi,
>>
>> Thanks for your help! I've checked the sources that you mentioned.
>> Currently, I think that I would need to implement a
>> FunctionToLoopNestPassAdaptor which is essentially the same as the
>> FunctionToLoopPassAdaptor but operates only on LI.getTopLevelLoops().
>>
>> We might also need a LNPMUpdater (LoopNestPassManagerUpdater) which
>> disallows adding inner-loops back into the pipeline, and
>> LoopNestPassManager will simply be PassManager<Loop, LoopAnalysisManager,
>> LoopStandardAnalysisResult &, LNPMUpdater &>.
>>
>> One question I have is whether the IRUnit LoopNestPass operates on should
>> be Loop or LoopNest, since I'm not quite sure about the usage of LoopNest
>> and why it should be constructed with a ScalarEvolution.
>>
>> Also, it is stated that "we want to create a LoopNestPass, where
>> transformations intended for loop nest can inherit from it" in the original
>> GSoC project description, but I believe that inheriting from a Pass
>> subclass is no longer required in the New Pass Manager. So should we also
>> implement a LoopNestPass subclass that allows implementing loop-nest-passes
>> for the Legacy Pass Manager?
>>
>> Finally, I have some questions that might not be very relevant to the
>> project. But currently, how does the LegacyPassManager and the
>> NewPassManager interact? Also, is it possible to add passes designed for
>> LegacyPassManager into the NewPassManager and vice versa?
>>
>> What do you think about the plan? I'm quite likely to miss something
>> important, so please kindly correct me if I'm in the wrong direction.
>>
>> Thank you very much!
>> Sincerely, Ta-Wei Tu
>>
>> Whitney Tsang <*whitney.uwaterloo at gmail.com*
>> <whitney.uwaterloo at gmail.com>> 於 2020年7月15日 週三 下午6:14寫道：
>>
>> - Hi Wayne,
>>
>> As far as I know, no one is working on this project. Your
>> contribution is always appreciated.
>>
>> This project aims to create LoopNestPass in the new pass manager
>> (NPM).
>> In *https://www.youtube.com/watch?v=3pRhvQi7Z10*
>> <https://www.youtube.com/watch?v=3pRhvQi7Z10> , you can try to follow
>> along to create a LLVM loop pass in NPM.
>>
>> There exist different kinds of passes in the NPM, e.g. ModulePass,
>> FunctionPass, LoopPass.
>> One or more loop passes can be added in a LoopPassManager, which then
>> can be added in FunctionPassManager through
>> createFunctionToLoopPassAdaptor.
>> Examples can be found in llvm/lib/Passes/PassBuilder.cpp.
>> There exist passes that best operate as a loop nest, e.g.
>> LoopInterchange. For those passes, currently can be written as either
>> FunctionPass or LoopPass.
>> However, choosing one or the other needs to sacrifice the ability of
>> the other.
>> The idea of a LoopNestPass is to combine the benefits of FunctionPass
>> and LoopPass needed for a loop nest.
>>
>> On top of LoopNest I would suggest to also get familiar with
>> different PassAdaptor classes (e.g. FunctionToLoopPassAdaptor).
>> - llvm/include/llvm/Transforms/Scalar/LoopPassManager.h
>>
>> I am happy to provide feedback once you have a plan of how to
>> proceed, or review your patches on Phabricator.
>>
>> Regards,
>> Whitney Tsang
>>
>> On Wed, Jul 15, 2020 at 5:49 AM Wayne Tu via llvm-dev <
>> *llvm-dev at lists.llvm.org* <llvm-dev at lists.llvm.org>> wrote:
>> - Hi,
>>
>> I'm a college student who is quite new to the community and is
>> interested in contributing to the LLVM project. Although I haven't applied
>> to GSoC, I notice that the project "Create LoopNestPass" seems to be
>> unassigned.
>> So I'm curious whether anyone is currently working on it, and if
>> not, is it possible for me to work on it as a side-project?
>>
>> I've been programming in C++ for quite a while, and I've walked
>> through the `LoopPass`, `LoopNest`, and some other LLVM classes that I
>> think would probably be related to this project. I've also watched some of
>> the videos in the llvm-dev conference regarding loops, so I now have a
>> rough idea on how to implement the LoopNestPass.
>>
>> I'm looking forward to working on this project.
>>
>> Thank you very much.
>>
>> Sincerely,
>> Ta-Wei Tu
>> _______________________________________________
>> LLVM Developers mailing list
>> *llvm-dev at lists.llvm.org* <llvm-dev at lists.llvm.org>
>> *https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev*
>> <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200724/e4f4b3a4/attachment-0001.html>
More information about the llvm-dev
mailing list