<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi,<div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 11, 2019, at 17:51, Bardia Mahjour via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><p class=""><font size="2" class="">---------------------------</font><br class=""><font size="2" class="">Wed, Sep 11, 2019:</font><br class=""><font size="2" class="">---------------------------</font><br class=""><br class=""><font size="2" class="">- LICM vs Loop Sink Strategy (Whitney)</font><br class=""><font size="2" class=""> - LICM and SCEV expander host code with no regards to increased </font><br class=""><font size="2" class=""> live-ranges. This is a long standing issue where historically </font><br class=""><font size="2" class=""> preference has been to keep LICM more aggressive.</font><br class=""></p></div></div></blockquote><div><br class=""></div>This issue also motivated adding metadata to disable LICM (l<span style="color: rgba(0, 0, 0, 0.85098); font-family: "Helvetica Neue";" class="">lvm.loop.licm.disable) recently. </span><a href="https://reviews.llvm.org/D64557" class="">https://reviews.llvm.org/D64557</a><blockquote type="cite" class=""><div class=""><div class=""><p class=""><font size="2" class=""> - Two questions from IBM side:</font><br class=""><font size="2" class=""> a. This problem is not specific to the POWER platform, so we are</font><br class=""><font size="2" class=""> wondering if other people are interested?</font><br class=""><font size="2" class=""> - b. Where would be the best place to address this issue?</font><br class=""><font size="2" class=""> - Since it's hard to come up with an accurate register pressure </font><br class=""><font size="2" class=""> estimator in opt, it's probably better to be done fairly late,</font><br class=""><font size="2" class=""> maybe after instruction scheduling.</font><br class=""><font size="2" class=""> - A good place to start would be instruction re-materialization in </font><br class=""><font size="2" class=""> the register allocator.</font><br class=""><font size="2" class=""> - Problem is the logic in the register allocator can deal with a </font><br class=""><font size="2" class=""> single instruction (instead of groups of instructions) at a time.</font><br class=""><font size="2" class=""> - Start by handling one single-instruction at a time and apply the</font><br class=""><font size="2" class=""> same logic to groups of instructions iteratively to see the </font><br class=""><font size="2" class=""> impact on performance and compile-time.</font><br class=""><font size="2" class=""> - live-range editor may have utilities to help with code motion.</font><br class=""><font size="2" class=""> - lazy-code-motion may be a good long term solution, but no one seems</font><br class=""><font size="2" class=""> to be actively working on it.</font><br class=""><br class=""><font size="2" class="">- Announcements: </font><br class=""><font size="2" class=""> - flang call moved so we are no longer in conflict!</font><br class=""><br class=""><font size="2" class=""> - Philip is working on making loop vectorizer robust in the face of </font><br class=""><font size="2" class=""> multiple exits. There are two subproblems</font><br class=""><font size="2" class=""> 1. vectorizer currently gives up because scev is not giving exit </font><br class=""><font size="2" class=""> counts (due to a bug?). This is relatively easy to fix and</font><br class=""><font size="2" class=""> Philip will have a patch for it soon.</font><br class=""><font size="2" class=""> 2. loop exit cannot be analyzed due to data dependent exit, which</font><br class=""><font size="2" class=""> is currently handled via predication. There is a lot of room</font><br class=""><font size="2" class=""> for improvement, specially for read-only loops. </font><br class=""><font size="2" class=""> Please let him know if you are interested.</font><br class=""><br class=""><br class=""><font size="2" class="">- Status Updates</font><br class=""><font size="2" class=""> - Data Dependence Graph (</font><a href="https://reviews.llvm.org/D65350" class=""><font size="2" class="">https://reviews.llvm.org/D65350</font></a><font size="2" class="">) (Bardia)</font><br class=""><font size="2" class=""> - All review comments are addressed. Waiting for approval.</font><br class=""><font size="2" class=""> - Bugzilla bugs update (Vivek)</font><br class=""><font size="2" class=""> - Florian has a patch fixing loop bugs related to max trip count.</font><br class=""><br class=""><font size="2" class="">----------------------------</font><br class=""><font size="2" class="">Tentative Agenda for Sept 25</font><br class=""><font size="2" class="">----------------------------</font><br class=""><br class=""><font size="2" class="">Presentation from Marc Moreno Maza about his work on delinearization.</font><br class=""><br class=""><font size="2" class="">- Status Updates</font><br class=""><font size="2" class=""> - Follow up on multi-dimensional array indexing RFC (Siddharth)</font><br class=""><font size="2" class=""> - Impact of Loop Rotation on existing passes (Min-Yih)</font><br class=""><font size="2" class=""> - Data Dependence Graph (</font><a href="https://reviews.llvm.org/D65350" class=""><font size="2" class="">https://reviews.llvm.org/D65350</font></a><font size="2" class="">) (Bardia)</font><br class=""><font size="2" class=""> - Bugzilla bugs update (Vivek)</font><br class=""><font size="2" class=""> - Others?</font><br class=""><br class=""><br class=""><font size="2" class="">Bardia Mahjour<br class="">Compiler Optimizations<br class="">IBM Toronto Software Lab</font><br class="">
</p></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></div></body></html>