<html><body><p><font size="2">Wed, Jun 5th, 2019:</font><br><font size="2">--------------------------</font><br><br><font size="2">Meeting Minutes:</font><br><br><font size="2">- The meeting started with an introduction round table where everyone briefly shared their experience in LLVM and expressed their interests in loop optimizations.</font><br><font size="2">- Decisions Made:</font><br><font size="2"> - Run the meetings on a bi-weekly bases.</font><br><font size="2"> - Participants working on specific loop optimization related work to give a quick update in each meeting about their work, in order to create awareness and avoid duplication of effort.</font><br><font size="2"> - Meeting Minutes and Agenda to be sent to the llvm-dev mailing list.</font><br><font size="2">- The following topics where discussed as potential items in the agenda for future meetings. Michael and Bardia to chose topics for the first few meeting based on this list:</font><br><br><br><font size="2">1) Missing utilities and infrastructure. WG to think about infrastructure (small or large) that can facilitate multiple loop transformations, for example to avoid doing tedious and repetitive work over and over again:</font><br><font size="2"> - Loop Utilities</font><br><font size="2"> - DDG</font><br><font size="2"> - Loop Distribution Interference Graph to allow the transformation to be invoked with different policies (eg. perfect loop nest creation, improving locality of reference, etc)</font><br><font size="2"> - Concept of a Loop Nest and a Perfect Loop Nest</font><br><font size="2"> - Ideas that help with (or minimize/avoid) the tedious mechanics of updating loops, or keeping results of analysis up-to-date as various transformations are performed.</font><br><br><font size="2">2) Abstracting away loop structures to do transformations at a higher level representation. </font><br><br><font size="2">3) Refactoring opportunities for existing transformations where there is duplication and no reuse</font><br><font size="2"> - eg. Loop Unroll, Unroll-and-jam and Peeling can be refactored.</font><br><br><font size="2">4) Rewriting existing transformations that have severe limitations in terms of functionality, performance, maintainability, etc. </font><br><font size="2"> - Acceptable only if there is commitment to replace the old implementation within a reasonable timeline.</font><br><br><font size="2">5) Reviewing open bugs and see which ones are critical to solve.</font><br><br><font size="2">6) Sharing results across common set of bmks, instead of each party having their own. </font><br><font size="2"> - Involves a lot of work, so need to be mindful of time commitment and resources available.</font><br><font size="2"> - Improving coverage in the test suite by migrating benchmark codes into it. IR level benchmarking still fragile. </font><br><font size="2"> - Coming up with synthetic benchmarks to test that the right set of transformations are done in the right order to produce significantly more simplified/performant code.</font><br><br><font size="2">7) Polyhedral Optimizations in LLVM.</font><br><font size="2"> - Collaboration with the MLIR team in ANL.</font><br><font size="2"> - Possibility of exposing polyhedral analysis to other non-poly transformations.</font><br><br><font size="2">8) Cost-Models</font><br><font size="2"> - High quality models necessary to achieve good performance out of existing and new loop transformations.</font><br><br><font size="2">9) Canonicity</font><br><font size="2"> - What is canonical form for loops, loop nests, etc.</font><br><font size="2"> - Currently some (many?) loop transformation can only handle canonical loops, failing if input is not in an expected form.</font><br><font size="2"> - Phase ordering and the loop optimization pipeline.</font><br><br><font size="2">10) Establishing goals for LLVM dev conference in fall. Collectively come up with material for a BoF or a talk to present the types of work that WG is involved in.</font><br><br><font size="2">11) Giving educational talks at the bi-weekly meetings and sharing educational material and presentations with the community.</font><br><br><font size="2">12) Looking into why we have so many loop passes that are disabled by default. Investigate if it's due to lack of cost-modeling, functional correctness, etc?</font><br><br><font size="2">Bardia Mahjour<br>Compiler Optimizations<br>Hydra Squad Lead<br>IBM Toronto Software Lab<br>bmahjour@ca.ibm.com (905) 413-2336<br><br></font><BR>
</body></html>