[llvm-dev] Regarding the project "Create LoopNestPass"
Ta-Wei Tu via llvm-dev
llvm-dev at lists.llvm.org
Thu Jul 23 22:27:22 PDT 2020
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/dc98c2c4/attachment-0001.html>
More information about the llvm-dev
mailing list