RetroSearch Browse

Thu Jul 23 22:27:22 PDT 2020 · https://lists.llvm.org/pipermail/llvm-dev/2020-July/143729.html

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>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://lists.llvm.org/pipermail/llvm-dev/2020-July/143729.html below:

[llvm-dev] Regarding the project "Create LoopNestPass"