<html><body><p><font size="2">---------------------------</font><br><font size="2">Wed, Sep 11, 2019:</font><br><font size="2">---------------------------</font><br><br><font size="2">- LICM vs Loop Sink Strategy (Whitney)</font><br><font size="2"> - LICM and SCEV expander host code with no regards to increased </font><br><font size="2"> live-ranges. This is a long standing issue where historically </font><br><font size="2"> preference has been to keep LICM more aggressive.</font><br><font size="2"> - Two questions from IBM side:</font><br><font size="2"> a. This problem is not specific to the POWER platform, so we are</font><br><font size="2"> wondering if other people are interested?</font><br><font size="2"> - b. Where would be the best place to address this issue?</font><br><font size="2"> - Since it's hard to come up with an accurate register pressure </font><br><font size="2"> estimator in opt, it's probably better to be done fairly late,</font><br><font size="2"> maybe after instruction scheduling.</font><br><font size="2"> - A good place to start would be instruction re-materialization in </font><br><font size="2"> the register allocator.</font><br><font size="2"> - Problem is the logic in the register allocator can deal with a </font><br><font size="2"> single instruction (instead of groups of instructions) at a time.</font><br><font size="2"> - Start by handling one single-instruction at a time and apply the</font><br><font size="2"> same logic to groups of instructions iteratively to see the </font><br><font size="2"> impact on performance and compile-time.</font><br><font size="2"> - live-range editor may have utilities to help with code motion.</font><br><font size="2"> - lazy-code-motion may be a good long term solution, but no one seems</font><br><font size="2"> to be actively working on it.</font><br><br><font size="2">- Announcements: </font><br><font size="2"> - flang call moved so we are no longer in conflict!</font><br><br><font size="2"> - Philip is working on making loop vectorizer robust in the face of </font><br><font size="2"> multiple exits. There are two subproblems</font><br><font size="2"> 1. vectorizer currently gives up because scev is not giving exit </font><br><font size="2"> counts (due to a bug?). This is relatively easy to fix and</font><br><font size="2"> Philip will have a patch for it soon.</font><br><font size="2"> 2. loop exit cannot be analyzed due to data dependent exit, which</font><br><font size="2"> is currently handled via predication. There is a lot of room</font><br><font size="2"> for improvement, specially for read-only loops. </font><br><font size="2"> Please let him know if you are interested.</font><br><br><br><font size="2">- Status Updates</font><br><font size="2"> - Data Dependence Graph (</font><a href="https://reviews.llvm.org/D65350"><font size="2">https://reviews.llvm.org/D65350</font></a><font size="2">) (Bardia)</font><br><font size="2"> - All review comments are addressed. Waiting for approval.</font><br><font size="2"> - Bugzilla bugs update (Vivek)</font><br><font size="2"> - Florian has a patch fixing loop bugs related to max trip count.</font><br><br><font size="2">----------------------------</font><br><font size="2">Tentative Agenda for Sept 25</font><br><font size="2">----------------------------</font><br><br><font size="2">Presentation from Marc Moreno Maza about his work on delinearization.</font><br><br><font size="2">- Status Updates</font><br><font size="2"> - Follow up on multi-dimensional array indexing RFC (Siddharth)</font><br><font size="2"> - Impact of Loop Rotation on existing passes (Min-Yih)</font><br><font size="2"> - Data Dependence Graph (</font><a href="https://reviews.llvm.org/D65350"><font size="2">https://reviews.llvm.org/D65350</font></a><font size="2">) (Bardia)</font><br><font size="2"> - Bugzilla bugs update (Vivek)</font><br><font size="2"> - Others?</font><br><br><br><font size="2">Bardia Mahjour<br>Compiler Optimizations<br>IBM Toronto Software Lab</font><BR>
</body></html>