[www] r342224 - Added missing BoF to the program.

Fri Sep 14 04:20:48 PDT 2018

Author: stulova
Date: Fri Sep 14 04:20:48 2018
New Revision: 342224

URL: http://llvm.org/viewvc/llvm-project?rev=342224&view=rev
Log:
Added missing BoF to the program.


Modified:
    www/trunk/devmtg/2018-10/index.html
    www/trunk/devmtg/2018-10/talk-abstracts.html

Modified: www/trunk/devmtg/2018-10/index.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2018-10/index.html?rev=342224&r1=342223&r2=342224&view=diff
==============================================================================

--- www/trunk/devmtg/2018-10/index.html (original)
+++ www/trunk/devmtg/2018-10/index.html Fri Sep 14 04:20:48 2018
@@ -151,10 +151,10 @@ Details coming soon. Workshop from 1-5 f
     <li><a href="talk-abstracts.html#bof0">Lifecycle of LLVM bug reports</a> - Kristof Beyls, Paul Robinson</li>
     <li><a href="talk-abstracts.html#bof2">GlobalISel Design and Development</a> - Amara Emerson</li>
     <li><a href="talk-abstracts.html#bof3">Migrating to C++14, and beyond!</a> - JF Bastien</li>
-    <li><a href="talk-abstracts.html#bof4">Ideal versus Reality: Optimal Parallelism and Offloading Support in LLVM</a> - Xinmin Tian, Hal Finkel, TB Schardl, Johannes Doerfert, Vikram Adve</li>
+    <li><a href="talk-abstracts.html#bof4">Ideal versus Reality: Optimal Parallelism and Offloading Support in LLVM</a> - Xinmin Tian, Hal Finkel, TB Schardl, Johannes Doerfert, Vikram Adve <a href="talk-abstracts.html#bof7">Should we go beyond `#pragma omp declare simd`?</a> - Francesco Petrogalli</li>
     <li><a href="talk-abstracts.html#bof5">Implementing the parallel STL in libc++</a> - Louis Dionne</li>
     <li><a href="talk-abstracts.html#bof6">Clang Static Analyzer BoF</a> - Devin Coughlin</li>
-    <li><a href="talk-abstracts.html#bof7">LLVM Foundation BoF</a> - LLVM Foundation Board of Directors</li>
+    <li><a href="talk-abstracts.html#bof8">LLVM Foundation BoF</a> - LLVM Foundation Board of Directors</li>
 </ul>
     <b>Lightning Talks</b>
 <ul>

Modified: www/trunk/devmtg/2018-10/talk-abstracts.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2018-10/talk-abstracts.html?rev=342224&r1=342223&r2=342224&view=diff
==============================================================================
--- www/trunk/devmtg/2018-10/talk-abstracts.html (original)
+++ www/trunk/devmtg/2018-10/talk-abstracts.html Fri Sep 14 04:20:48 2018
@@ -376,7 +376,24 @@ This BoF will provide an opportunity for
 </p>
 </li>
 	
-    <li><a id="bof7">LLVM Foundation BoF</a>
+<li><a id="bof7">Should we go beyond `#pragma omp declare simd`?</a>
+	<br><i>Francesco Petrogalli</i>
+<p>
+BoF for the people involved in the development of the interface between the compiler and the vector routines provided by a library (including C99 math functions), or via user code. The discussion is ongoing in the ML [1] http://lists.llvm.org/pipermail/llvm-dev/2018-July/124520.html
+</p><p>
+Problem statement: "How should the compiler know about which vector functions are available in a library or in a module when auto-vectorizing scalar calls, when standards like OpenMP and Vector Function ABIs cannot provide a 1:1 mapping from the scalar functions to the vector one?".
+</p><p>
+Practical example of the problem:
+</p><p>
+1. library L provides vector `sin` for target T operating on four lanes, but in two versions: a _slow_ vector `sin` that guarantee high precision, and a _fast_ version with lazy requirement on precision. How should the compiler allow the user to choose between the two? 2. A user can write serial code and rely on the auto-vectorization capabilities of the compiler to generate vector functions using the `#pragma omp declare simd` directive of OpenMP. Sometimes the compiler doesn't do a good job in vectorizing such functions, because not all the micro-architectural capabilities of a vector extension can be exposed in the vectorizer pass. This situation often forces a user to write target specific vector loops that invoke a target specific implementation of the vector function, mostly via pre-processor directive that reduce the maintainability and portability of the code. How can we help clang users to avoid such situation? Could they rely on the compiler in picking up the correct version of the vector function without modifying the original code other than adding the source of the hand optimized version of the vector function?
+</p><p>
+Proposed schedule:
+</p><p>
+1. Enunciate the problem that we are trying to solve. 2. List the proposed solutions. 3. Discuss pros and cons of each of them. 4. Come up with a common plan that we can implement in clang/LLVM.
+</p>
+</li>
+
+    <li><a id="bof8">LLVM Foundation BoF</a>
 	 <br><i>LLVM Foundation Board of Directors</i><br>
 	<p>
 	Ask the LLVM Foundation Board of Directors anything, get program updates, and meet the new board members


