[www] r297299 - Multiple changes to EuroLLVM'17 page (3 in total, individual messages following)

Kevin Streit via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 8 09:54:11 PST 2017


Author: streit
Date: Wed Mar  8 11:54:10 2017
New Revision: 297299

URL: http://llvm.org/viewvc/llvm-project?rev=297299&view=rev
Log:
Multiple changes to EuroLLVM'17 page (3 in total, individual messages following)


Fix wording in abstract.

On behalf of Johannes Doerfert <johannes at jdoerfert.de> (Wed Mar 8 19:01:08 2017 +0100)


Add author

On behalf of Johannes Doerfert <johannes at jdoerfert.de> (Wed Mar 8 14:12:04 2017 +0100)


Fix poster abstract

On behalf of Johannes Doerfert <johannes at jdoerfert.de> (Wed Mar 8 14:11:44 2017 +0100)

Modified:
    www/trunk/devmtg/2017-03/2017/02/20/accepted-sessions.html

Modified: www/trunk/devmtg/2017-03/2017/02/20/accepted-sessions.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2017-03/2017/02/20/accepted-sessions.html?rev=297299&r1=297298&r2=297299&view=diff
==============================================================================
--- www/trunk/devmtg/2017-03/2017/02/20/accepted-sessions.html (original)
+++ www/trunk/devmtg/2017-03/2017/02/20/accepted-sessions.html Wed Mar  8 11:54:10 2017
@@ -415,6 +415,12 @@ Bugfixing or new feature development req
      <p class="affiliation">
       Ericsson
      </p>
+     <p class="author">
+      Peter Szecsi
+     </p>
+     <p class="affiliation">
+      ELTE
+     </p>
 
      <p class="kind">
       Technical Talk
@@ -594,7 +600,7 @@ The LLVM compiler follows closely the co
        Introducing VPlan to the Loop Vectorizer
      </p>
      <p class="abstract">
-This talk describes our efforts to refactor LLVM’s Loop Vectorizer following the RFC posted on llvm-dev mailing list[1] and the presentation delivered at LLVM-US 2016[2]. We describe the design and initial implementation of VPlan which models the vectorized code and drives its transformation.<br /><br />In this talk we cover the main aspects implemented in our first proposed major patch[3]. These include introducing a Planning step into the Loop Vectorizer which follows its Legality step. The refactored Loop Vectorizer records in VPlans all vectorization decisions taken inside a candidate vectorized loop body, and uses the best VPlan to carry them out. These decisions specify which instructions are to<br />  + be vectorized naturally, or<br />  + be part of an interleave group, or<br />  + be scalarized, and<br />  + be packed or unpacked - at the definition rather than at its uses - to  provide both scalarized and vectorized forms.<br /><br />VPlan also explicitly represents a
 ll control-flow within the loop body of the vectorized code. The Planner can optionally sink to-be scalarized instructions into predicated basic blocks in VPlan, thereby converting a current post-vectorization optimization of the Loop Vectorizer into the Planning step. Once the Planning step concludes a best VPlan is selected; this VPlan drives the vectorization transformation itself, including both the generation of basic-blocks and the generation of new instructions filling them, reusing existing Loop Vectorizer routines.<br /><br />The VPlan model implemented strives to be compact, addressing compile-time concerns. We conclude the talk by presenting ongoing and planned future steps for incremental refactoring of the Loop Vectorizer following our proposed patch[3] and the roadmap outlined in the LLVM-US presentation[2].<br /><br />Joint work with the Intel vectorization team.<br /><br />[1] [llvm-dev] RFC: Extending LV to vectorize outerloops, http://lists.llvm.org/pipermail/llvm-
 dev/2016-September/105057.htm.<br />[2] Extending LoopVectorizer towards supporting OpenMP4.5 SIMD and outer loop auto-vectorization, 2016 LLVM Developers' Meeting, https://www.youtube.com/watch?v=XXAvdUwO7k.<br />[3] [LV] Introducing VPlan to model the vectorized code and drive its transformation, https://reviews.llvm.org/D28975
+This talk describes our efforts to refactor LLVM’s Loop Vectorizer following the RFC posted on llvm-dev mailing list[1] and the presentation delivered at LLVM-US 2016[2]. We describe the design and initial implementation of VPlan which models the vectorized code and drives its transformation.<br /><br />In this talk we cover the main aspects implemented in our first proposed major patch[3]. These include introducing a Planning step into the Loop Vectorizer which follows its Legality step. The refactored Loop Vectorizer records in VPlans all vectorization decisions taken inside a candidate vectorized loop body, and uses the best VPlan to carry them out. These decisions specify which instructions are to<br />  + be vectorized naturally, or<br />  + be part of an interleave group, or<br />  + be scalarized, and<br />  + be packed or unpacked - at the definition rather than at its uses - to  provide both scalarized and vectorized forms.<br /><br />VPlan also explicitly represents a
 ll control-flow within the loop body of the vectorized code. The Planner can optionally sink to-be scalarized instructions into predicated basic blocks in VPlan, thereby converting a current post-vectorization optimization of the Loop Vectorizer into the Planning step. Once the Planning step concludes a best VPlan is selected; this VPlan drives the vectorization transformation itself, including both the generation of basic-blocks and the generation of new instructions filling them, reusing existing Loop Vectorizer routines.<br /><br />The VPlan model implemented strives to be compact, addressing compile-time concerns. We conclude the talk by presenting ongoing and planned future steps for incremental refactoring of the Loop Vectorizer following our proposed patch[3] and the roadmap outlined in the LLVM-US presentation[2].<br /><br />Joint work of the Intel vectorization team.<br /><br />[1] [llvm-dev] RFC: Extending LV to vectorize outerloops, http://lists.llvm.org/pipermail/llvm-de
 v/2016-September/105057.htm.<br />[2] Extending LoopVectorizer towards supporting OpenMP4.5 SIMD and outer loop auto-vectorization, 2016 LLVM Developers' Meeting, https://www.youtube.com/watch?v=XXAvdUwO7k.<br />[3] [LV] Introducing VPlan to model the vectorized code and drive its transformation, https://reviews.llvm.org/D28975
      </p>
      </td>
     </tr>
@@ -1530,7 +1536,7 @@ Often application source code is not ava
        CodeCompass: An Open Software Comprehension Framework
      </p>
      <p class="abstract">
-Bugfixing or new feature development requires a confident understanding of all details and consequences of the planned changes. For long existing large telecom systems, where the code base have been developed and maintained for decades by fluctuating teams, original intentions are lost, the documentation is untrustworthy or missing, the only reliable information is the code itself. Code comprehension of such large software systems is an essential, but usually very challenging task. As the method of comprehension is fundamentally different from writing new code, development tools are not performing well. During the years, different programs have been developed with various complexity and feature set for code comprehension but none of them fulfilled all requirements.<br /><br />CodeCompass is an open source LLVM/Clang based tool developed by Ericsson Ltd. and the Eötvös Loránd University, Budapest to help understanding large legacy software systems. Based on the LLVM/Clang co
 mpiler infrastructure, CodeCompass gives exact information on complex C/C++ language elements like overloading, inheritance, the (read or write) usage of variables, possible call. on function pointers and the virtual functions -- features that various existing tools support only partially. The wide range of interactive visualizations extends further than the usual class and function call diagrams; architectural, component and interface diagrams are a few of the implemented graphs.<br /><br />To make comprehension more extensive, CodeCompass is not restricted to the source code. It also utilizes build information to explore the system architecture as well as version control information when available: git commit history and blame view are also visualized. Clang based static analysis results are also integrated to CodeCompass. Although the tool focuses mainly on C and C++, it also supports Java and Python languages. Having a web-based, pluginable, extensible architecture, the CodeComp
 ass framework can be an open platform to further code comprehension, static analysis and software metrics efforts.<br /><br />Lecture outline:<br />- First we show why current development tools are not satisfactory for code comprehension<br />- Then we specify the requirements for such a tool<br />- Introduce codecompass architecture.<br />- Revail some challenges we have met and how we solve them<br />- Show a live demo<br />- Describe the open architecture and<br />- Talk about future plans and how the community can extend the feature set
+Bugfixing or new feature development requires a confident understanding of all details and consequences of the planned changes. For long existing large telecom systems, where the code base have been developed and maintained for decades by fluctuating teams, original intentions are lost, the documentation is untrustworthy or missing, the only reliable information is the code itself. Code comprehension of such large software systems is an essential, but usually very challenging task. As the method of comprehension is fundamentally different from writing new code, development tools are not performing well. During the years, different programs have been developed with various complexity and feature set for code comprehension but none of them fulfilled all requirements.<br /><br />CodeCompass is an open source LLVM/Clang based tool developed by Ericsson Ltd. and the Eötvös Loránd University, Budapest to help understanding large legacy software systems. Based on the LLVM/Clang co
 mpiler infrastructure, CodeCompass gives exact information on complex C/C++ language elements like overloading, inheritance, the (read or write) usage of variables, possible calls on function pointers and the virtual functions -- features that various existing tools support only partially. The wide range of interactive visualizations extends further than the usual class and function call diagrams; architectural, component and interface diagrams are a few of the implemented graphs.<br /><br />To make comprehension more extensive, CodeCompass is not restricted to the source code. It also utilizes build information to explore the system architecture as well as version control information when available: git commit history and blame view are also visualized. Clang based static analysis results are also integrated to CodeCompass. Although the tool focuses mainly on C and C++, it also supports Java and Python languages. Having a web-based. pluginable, extensible architecture, the CodeComp
 ass framework can be an open platform to further code comprehension, static analysis and software metrics efforts. 
      </p>
      </td>
     </tr>




More information about the llvm-commits mailing list