- User Since
- Mar 1 2021, 7:43 AM (20 w, 4 d)
Wed, Jul 14
Wed, Jun 30
Tue, Jun 29
Yes, you're right. My explanation was confusing.
We're thinking of replacing LICM in LPM1 with LNICM and adding LPM3 containing LICM after LPM2.
In long term, LPM3 should be removed though.
Sat, Jun 26
I am sorry to make you have any unintentional negative feelings. English is not my first language.
I appreciate all review comments I have gotten. I will try to have the motivation more up front next time.
Thu, Jun 24
I don't introduce a lot of changes for LNICM, and reuse as much code in LICM as possible.
Some transformations really benefit from perfect loop nest. One of the examples is loop-interchange as shown in a lit test.
LICM cannot maintain perfect loop nest, so we need to add LNICM.
Jun 23 2021
Update a test case to show loop-interchange doesn't run after running LICM but LNICM.
Is LoopNest Invariant Code Motion Pass only about not doing the movement that breaks perfect loop nest?
What about all the code that is no longer moved?
What is the envisioned final pipeline structure?
Do we end up having to run both LNICM and LICM?
Yes, we need to run both LNICM and LICM. Sometimes we should run either one.
Jun 22 2021
Add a test case to demonstrate that LNICM hoists invariants only out of loop nest and keeps perfect loop nest.
Jun 20 2021
I'm sorry to be late to reply.
I'm making small tests and some code changes to demonstrate the following:
Jun 15 2021
LNICM itself is no faster, but we can expect other optimizations to run thanks to LNICM and may be able to get more optimized code.
Actually, LNICM is to enable other optimizations in loop pipeline that require perfect loop nest by hoisting innermost invariants out of loop nest at once.
I said that LNICM can efficiently perform LICM, but after tweaking the code and running some tests, I realized that it might not get faster.
However, even if it gets no faster, LNICM is worth adding as a new pass.
Jun 12 2021
As the patch is written I am concerned that this appears to mostly duplicate the existing code of LICM (which adds a maintenance burden) and just changes the type of the pass.
I'll update the code to contain less duplication. I'm sorry to trouble you.
Jun 7 2021
Just a small change.
Jun 6 2021
Code updated. No crash on legacy pass manager in my environment.
May 27 2021
May 25 2021
Maybe fixed the problem.
May 24 2021
Thank you for reporting. I'll revert the commit and fix the problem.
May 22 2021
To avoid a failure by address sanitizer
May 11 2021
The pre-merge checks failed, so I fixed it.
Updated the code. Thanks.
Mar 26 2021
Updated the code
Mar 25 2021
Does it work, in general, to have a loop pass that creates and destroys loops? Even if the outer loop is completely unrolled?
I should have added code like
if (Result == LoopUnrollResult::FullyUnrolled) LPM.markLoopAsDeleted(*L);
after calling tryToUnrollAndJamLoop.
Mar 23 2021
Followed clang-tidy's warning