[llvm-dev] Regarding the project "Create LoopNestPass"
Ta-Wei Tu via llvm-dev
llvm-dev at lists.llvm.org
Wed Jul 29 12:41:57 PDT 2020
Hi,
I've just submitted the patch to Phabricator:
https://reviews.llvm.org/D84886 and I've added you as reviewers.
Please kindly provide feedback on the patch.
Thank you very much!
Sincerely,
Ta-Wei Tu
Whitney T Tsang <whitneyt at ca.ibm.com> 於 2020年7月27日 週一 下午11:10寫道：
> > 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?
>
> If we allow putting LoopPass into LoopNestPass, then both cases should be
> supported, and it depends on the use case, similar idea as for "Module -
> CGCSS - Function" or "Module - Function".
> createModuleToPostOrderCGSCCPassAdaptor, createCGSCCToFunctionPassAdaptor,
> createModuleToFunctionPassAdaptor
>
> > 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?
>
> I prefer 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. You can specify in the description
> your intention and that tests are planning to be added.
>
> Regards,
> Whitney Tsang
>
> [image: Inactive hide details for Ta-Wei Tu ---2020/07/24 06:08:37
> AM---Hi, I misunderstood what addSiblingLoops() does - the analogy]Ta-Wei
> Tu ---2020/07/24 06:08:37 AM---Hi, I misunderstood what `addSiblingLoops()`
> does - the analogy should be
>
> From: Ta-Wei Tu <tu.da.wei at gmail.com>
> To: Ettore Tiotto <etiotto at ca.ibm.com>
> Cc: Whitney T Tsang <whitneyt at ca.ibm.com>, llvm-dev <
> llvm-dev at lists.llvm.org>, Whitney Tsang <whitney.uwaterloo at gmail.com>
> Date: 2020/07/24 06:08 AM
> Subject: [EXTERNAL] Re: [llvm-dev] Regarding the project "Create
> LoopNestPass"
> ------------------------------
>
>
>
> 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* <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* <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* <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* <tu.da.wei at gmail.com>>
> Cc: llvm-dev <*llvm-dev at lists.llvm.org* <llvm-dev at lists.llvm.org>>,
> Whitney Tsang <*whitney.uwaterloo at gmail.com*
> <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
>
>
> 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* <tu.da.wei at gmail.com>>
> To: Whitney Tsang <*whitney.uwaterloo at gmail.com*
> <whitney.uwaterloo at gmail.com>>
> Cc: llvm-dev <*llvm-dev at lists.llvm.org* <llvm-dev at lists.llvm.org>>,
> *whitneyt at ca.ibm.com* <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/20200730/cbd93878/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200730/cbd93878/attachment.gif>
More information about the llvm-dev
mailing list