[llvm-dev] Regarding the project "Create LoopNestPass"
Whitney T Tsang via llvm-dev
llvm-dev at lists.llvm.org
Mon Jul 27 08:10:18 PDT 2020
> 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
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> 於 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?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>
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>?於 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?, 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>?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
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/20200727/de89064a/attachment-0001.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/20200727/de89064a/attachment-0001.gif>
More information about the llvm-dev
mailing list