Thank you for the report. I'll look into it.
Mon, Sep 13
Sat, Sep 11
Fri, Sep 10
Tue, Aug 24
- No longer do findBestUnswitchTI every time we call unswitchBestCondition.
- Remove the condition BestUnswitchTIForLoopNest == findBestUnswitchTI, which was confusing.
Mon, Aug 23
For example, we may have an opportunity to perform loop-interchange (or some other transformations that require a perfect loop nest) after performing simple-loop-nest-unswitch.
We can perform simple-loop-unswitch after that, so there should be no problem for loop vectorization.
How we arrange passes including simple-loop-nest-unswitch in a pass pipeline is still a problem though...
Aug 21 2021
Aug 20 2021
Ready for review
Aug 18 2021
This patch is not ready for review. I'll update the diff soon.
Aug 16 2021
LGTM, thank you.
Aug 15 2021
Aug 9 2021
Added doc comment
Aug 5 2021
Added doc comment
Aug 4 2021
Jul 31 2021
Updated test to make it more readable
Jul 14 2021
Jun 30 2021
Jun 29 2021
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.
Jun 26 2021
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.
Jun 24 2021
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