[www] r291273 - Replace smart quotes
Ryan Govostes via llvm-commits
llvm-commits at lists.llvm.org
Fri Jan 6 11:54:04 PST 2017
Author: rgov
Date: Fri Jan 6 13:54:03 2017
New Revision: 291273
URL: http://llvm.org/viewvc/llvm-project?rev=291273&view=rev
Log:
Replace smart quotes
Modified:
www/trunk/devmtg/2016-11/index.html
Modified: www/trunk/devmtg/2016-11/index.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2016-11/index.html?rev=291273&r1=291272&r2=291273&view=diff
==============================================================================
--- www/trunk/devmtg/2016-11/index.html (original)
+++ www/trunk/devmtg/2016-11/index.html Fri Jan 6 13:54:03 2017
@@ -6,7 +6,7 @@
<tr><td valign="top">
<ol>
<li><a href="#about">About</a></li>
- <li><a href=â#program">Program</a></li>
+ <li><a href="#program">Program</a></li>
<li><a href="#abstracts">Talk Abstracts</a></li>
<li><a href="#contact">Contact</a></li>
</ol>
@@ -95,59 +95,59 @@ Please sign up for the
for future announcements and to ask questions.
</p>
-<div class="www_sectiontitle" id=âprogram">Program</div>
+<div class="www_sectiontitle" id="program">Program</div>
<p>The agenda may be found here: <a href="https://llvmdevelopersmeetingbay2016.sched.org">https://llvmdevelopersmeetingbay2016.sched.org</a></p>
-<p>Please view all videos on the <a href=âhttps://www.youtube.com/channel/UCv2_41bSAa5Y_8BacJUZfjQ">LLVM YouTube Channel</a>.</p>
+<p>Please view all videos on the <a href="https://www.youtube.com/channel/UCv2_41bSAa5Y_8BacJUZfjQ">LLVM YouTube Channel</a>.</p>
<table id="devmtg">
<tr><th>Media</th><th>Talk</th></tr>
-<tr><td><a href=âSlides/Hames-ORC.pdf">Slides</a><br><a href="https://youtu.be/hILdR8XRvdQ">Video</a></td><td><b><a href="#talk1">ORC -- LLVM's Next Generation of JIT API </a></b><br>Lang Hames</td></tr>
+<tr><td><a href="Slides/Hames-ORC.pdf">Slides</a><br><a href="https://youtu.be/hILdR8XRvdQ">Video</a></td><td><b><a href="#talk1">ORC -- LLVM's Next Generation of JIT API </a></b><br>Lang Hames</td></tr>
-<tr><td><a href=âSlides/Ansari-Code-Alignment.pdf">Slides</a><br><a href="https://youtu.be/IX16gcX4vDQ">Video</a></td><td><b><a href="#talk2">Causes of Performance Instability due to Code Placement in X86 </a></b><br>Zia Ansari</td></tr>
+<tr><td><a href="Slides/Ansari-Code-Alignment.pdf">Slides</a><br><a href="https://youtu.be/IX16gcX4vDQ">Video</a></td><td><b><a href="#talk2">Causes of Performance Instability due to Code Placement in X86 </a></b><br>Zia Ansari</td></tr>
-<tr><td><a href=âSlides/Finkel-IntrinsicsMetadataAttributes.pdf">Slides</a><br><a href="https://youtu.be/jII0AcgU_5c">Video</a></td><td><b><a href="#talk3">Intrinsics, Metadata, and Attributes: The story continues! </a></b><br>Hal Finkel</td></tr>
+<tr><td><a href="Slides/Finkel-IntrinsicsMetadataAttributes.pdf">Slides</a><br><a href="https://youtu.be/jII0AcgU_5c">Video</a></td><td><b><a href="#talk3">Intrinsics, Metadata, and Attributes: The story continues! </a></b><br>Hal Finkel</td></tr>
-<tr><td><a href=âSlides/Nishanov-LLVMCoroutines.pdf">Slides</a><br><a href="https://youtu.be/Ztr8QvMhqmQ">Video</a></td><td><b><a href="#talk4">LLVM Coroutines: Bringing resumable functions to LLVM </a></b><br>Gor Nishanov</td></tr>
+<tr><td><a href="Slides/Nishanov-LLVMCoroutines.pdf">Slides</a><br><a href="https://youtu.be/Ztr8QvMhqmQ">Video</a></td><td><b><a href="#talk4">LLVM Coroutines: Bringing resumable functions to LLVM </a></b><br>Gor Nishanov</td></tr>
-<tr><td><a href=âSlides/Emerson-ScalableVectorizationinLLVMIR.pdf">Slides</a><br><a href="https://youtu.be/0up2hJk7k94">Video</a></td><td><b><a href="#talk5">Scalable Vectorization for LLVM </a></b><br>Amara Emerson, Graham Hunter</td></tr>
+<tr><td><a href="Slides/Emerson-ScalableVectorizationinLLVMIR.pdf">Slides</a><br><a href="https://youtu.be/0up2hJk7k94">Video</a></td><td><b><a href="#talk5">Scalable Vectorization for LLVM </a></b><br>Amara Emerson, Graham Hunter</td></tr>
-<tr><td><a href=âSlides/Padlewski-DevirtualizationInLLVM.pdf">Slides</a><br><a href="https://youtu.be/qMhV6d3B1Vk">Video</a></td><td><b><a href="#talk6">Devirtualization in LLVM</a></b><br>Piotr Padlewski</td></tr>
+<tr><td><a href="Slides/Padlewski-DevirtualizationInLLVM.pdf">Slides</a><br><a href="https://youtu.be/qMhV6d3B1Vk">Video</a></td><td><b><a href="#talk6">Devirtualization in LLVM</a></b><br>Piotr Padlewski</td></tr>
-<tr><td><a href=âSlides/Saito-NextLevelLLVMLoopVectorizer.pdf">Slides</a><br><a href="https://youtu.be/XXAvdUwO7kQ">Video</a></td><td><b><a href="#talk7">Extending LoopVectorizer towards supporting OpenMP4.5 SIMD and outer loop auto-vectorization </a></b><br>Hideki Saito</td></tr>
+<tr><td><a href="Slides/Saito-NextLevelLLVMLoopVectorizer.pdf">Slides</a><br><a href="https://youtu.be/XXAvdUwO7kQ">Video</a></td><td><b><a href="#talk7">Extending LoopVectorizer towards supporting OpenMP4.5 SIMD and outer loop auto-vectorization </a></b><br>Hideki Saito</td></tr>
-<tr><td><a href=âSlides/Zolotukhin-LoopPasses.pdf">Slides</a><br><a href="https://youtu.be/AfeUG7f5UA0">Video</a></td><td><b><a href="#talk8">Loop Passes: Adding new features while reducing technical debt </a></b><br>Mikhail Zolotukhin</td></tr>
+<tr><td><a href="Slides/Zolotukhin-LoopPasses.pdf">Slides</a><br><a href="https://youtu.be/AfeUG7f5UA0">Video</a></td><td><b><a href="#talk8">Loop Passes: Adding new features while reducing technical debt </a></b><br>Mikhail Zolotukhin</td></tr>
-<tr><td><a href=âSlides/DiFederico-rev.ng.pdf">Slides</a><br><a href="https://youtu.be/5CbuU4KwBCE">Video</a></td><td><b><a href="#talk9">rev.ng: a QEMU- and LLVM-based static binary analysis framework </a></b><br>Alessandro Di Federico</td></tr>
+<tr><td><a href="Slides/DiFederico-rev.ng.pdf">Slides</a><br><a href="https://youtu.be/5CbuU4KwBCE">Video</a></td><td><b><a href="#talk9">rev.ng: a QEMU- and LLVM-based static binary analysis framework </a></b><br>Alessandro Di Federico</td></tr>
-<tr><td><a href=âSlides/Dunbar-NewArchitectureForBuildingSoftware.pdf">Slides</a><br><a href="https://youtu.be/b_T-eCToX1I">Video</a></td><td><b><a href="#talk10">A New Architecture for Building Software </a></b><br>Daniel Dunbar</td></tr>
+<tr><td><a href="Slides/Dunbar-NewArchitectureForBuildingSoftware.pdf">Slides</a><br><a href="https://youtu.be/b_T-eCToX1I">Video</a></td><td><b><a href="#talk10">A New Architecture for Building Software </a></b><br>Daniel Dunbar</td></tr>
-<tr><td><a href=âSlides/Kumar-Pop-GVNHoist.pdf">Slides</a><br><a href="https://youtu.be/GB3OpqSwuUw">Video</a></td><td><b><a href="#talk11">GVN-Hoist: Hoisting Computations from Branches </a></b><br>Aditya Kumar, Sebastian Pop</td></tr>
+<tr><td><a href="Slides/Kumar-Pop-GVNHoist.pdf">Slides</a><br><a href="https://youtu.be/GB3OpqSwuUw">Video</a></td><td><b><a href="#talk11">GVN-Hoist: Hoisting Computations from Branches </a></b><br>Aditya Kumar, Sebastian Pop</td></tr>
-<tr><td><a href=âSlides/Amini-Johnson-ThinLTO.pdf">Slides</a><br><a href="https://youtu.be/9OIEZAj243g">Video</a></td><td><b><a href="#talk12">ThinLTO: Scalable and Incremental LTO </a></b><br>Mehdi Amini, Teresa Johnson</td></tr>
+<tr><td><a href="Slides/Amini-Johnson-ThinLTO.pdf">Slides</a><br><a href="https://youtu.be/9OIEZAj243g">Video</a></td><td><b><a href="#talk12">ThinLTO: Scalable and Incremental LTO </a></b><br>Mehdi Amini, Teresa Johnson</td></tr>
-<tr><td><a href=âSlides/Lopes-LongLivePoison.pdf">Slides</a><br><a href="https://youtu.be/_-3Iiads1EM">Video</a></td><td><b><a href="#talk13">Killing poison and undef -- long live poison! </a></b><br>Juneyoung Lee, Nuno Lopes</td></tr>
+<tr><td><a href="Slides/Lopes-LongLivePoison.pdf">Slides</a><br><a href="https://youtu.be/_-3Iiads1EM">Video</a></td><td><b><a href="#talk13">Killing poison and undef -- long live poison! </a></b><br>Juneyoung Lee, Nuno Lopes</td></tr>
-<tr><td><a href=âSlides/Carlson-LeveragingIntermediateForms.pdf">Slides</a><br><a href="https://youtu.be/_xMUP09hmeM">Video</a></td><td><b><a href="#talk14">Leveraging Intermediate Forms for Analysis </a></b><br>Jared Carlson, Ayal Spitz</td></tr>
+<tr><td><a href="Slides/Carlson-LeveragingIntermediateForms.pdf">Slides</a><br><a href="https://youtu.be/_xMUP09hmeM">Video</a></td><td><b><a href="#talk14">Leveraging Intermediate Forms for Analysis </a></b><br>Jared Carlson, Ayal Spitz</td></tr>
-<tr><td><a href=âSlides/Nemet-Compiler-assistedPerformanceAnalysis.pdf">Slides</a><br><a href="https://youtu.be/qq0q1hfzidg">Video</a></td><td><b><a href="#talk15">Compiler-assisted Performance Analysis </a></b><br>Adam Nemet</td></tr>
+<tr><td><a href="Slides/Nemet-Compiler-assistedPerformanceAnalysis.pdf">Slides</a><br><a href="https://youtu.be/qq0q1hfzidg">Video</a></td><td><b><a href="#talk15">Compiler-assisted Performance Analysis </a></b><br>Adam Nemet</td></tr>
-<tr><td><a href=âSlides/Colombet-GlobalISel.pdf">Slides</a><br><a href="https://youtu.be/6tfb344A7w8">Video</a></td><td><b><a href="#talk16">Global Instruction Selection Status </a></b><br>Ahmed Bougacha, Quentin Colombet, Tim Northover</td></tr>
+<tr><td><a href="Slides/Colombet-GlobalISel.pdf">Slides</a><br><a href="https://youtu.be/6tfb344A7w8">Video</a></td><td><b><a href="#talk16">Global Instruction Selection Status </a></b><br>Ahmed Bougacha, Quentin Colombet, Tim Northover</td></tr>
-<tr><td><a href=âSlides/Braun-DealingWithRegisterHierarchies.pdf">Slides</a><br><a href="https://youtu.be/-TV77T1R7OU">Video</a></td><td><b><a href="#talk17">Dealing with Register Hierarchies </a></b><br>Matthias Braun</td></tr>
+<tr><td><a href="Slides/Braun-DealingWithRegisterHierarchies.pdf">Slides</a><br><a href="https://youtu.be/-TV77T1R7OU">Video</a></td><td><b><a href="#talk17">Dealing with Register Hierarchies </a></b><br>Matthias Braun</td></tr>
-<tr><td><a href=âSlides/Kleckner-CodeViewInLLVM.pdf">Slides</a><br><a href="https://youtu.be/5twzd06NqGU">Video</a></td><td><b><a href="#talk18">CodeView, the Microsoft Debug Info Format, in LLVM </a></b><br>Reid Kleckner</td></tr>
+<tr><td><a href="Slides/Kleckner-CodeViewInLLVM.pdf">Slides</a><br><a href="https://youtu.be/5twzd06NqGU">Video</a></td><td><b><a href="#talk18">CodeView, the Microsoft Debug Info Format, in LLVM </a></b><br>Reid Kleckner</td></tr>
-<tr><td><a href=âSlides/Sidorin-Summery-Based-Inter-Unit-Analysis.pdf">Slides</a><br><a href="https://youtu.be/jbLkZ82mYE4">Video</a></td><td><b><a href="#talk19">Summary-based inter-unit analysis for Clang Static Analyzer </a></b><br>Aleksei Sidorin</td></tr>
+<tr><td><a href="Slides/Sidorin-Summery-Based-Inter-Unit-Analysis.pdf">Slides</a><br><a href="https://youtu.be/jbLkZ82mYE4">Video</a></td><td><b><a href="#talk19">Summary-based inter-unit analysis for Clang Static Analyzer </a></b><br>Aleksei Sidorin</td></tr>
-<tr><td><a href=âSlides/Bieneman-CMake.pdf">Slides</a><br><a href="https://youtu.be/StF77Cx7pz8">Video</a></td><td><b><a href="#talk20">Developing and Shipping Clang with CMake</a></b><br>Chris Bieneman</td></tr>
+<tr><td><a href="Slides/Bieneman-CMake.pdf">Slides</a><br><a href="https://youtu.be/StF77Cx7pz8">Video</a></td><td><b><a href="#talk20">Developing and Shipping Clang with CMake</a></b><br>Chris Bieneman</td></tr>
-<tr><td><a href=âSlides/Paquette-Outliner.pdf">Slides</a><br><a href="https://youtu.be/yorld-WSOeU">Video</a></td><td><b><a href="#talk21">Reducing Code Size Using Outlining </a></b><br>Jessica Paquette</td></tr>
+<tr><td><a href="Slides/Paquette-Outliner.pdf">Slides</a><br><a href="https://youtu.be/yorld-WSOeU">Video</a></td><td><b><a href="#talk21">Reducing Code Size Using Outlining </a></b><br>Jessica Paquette</td></tr>
-<tr><td><a href=âSlides/Bowen-Hugett-ToyProgrammingDemo.pdf">Slides</a><br><a href="https://youtu.be/-pL94rqyQ6c">Video</a></td><td><b><a href="#talk22">Toy programming demo of a repository for statically compiled programs </a></b><br>Paul Bowen-Huggett</td></tr>
+<tr><td><a href="Slides/Bowen-Hugett-ToyProgrammingDemo.pdf">Slides</a><br><a href="https://youtu.be/-pL94rqyQ6c">Video</a></td><td><b><a href="#talk22">Toy programming demo of a repository for statically compiled programs </a></b><br>Paul Bowen-Huggett</td></tr>
-<tr><td><a href=âSlides/Cook-LLVM-Program-Integrity.pdf">Slides</a><br><a href="https://youtu.be/isHCLMrXPUk">Video</a></td><td><b><a href="#talk23">Using LLVM to guarantee program integrity </a></b><br>Simon Cook</td></tr>
+<tr><td><a href="Slides/Cook-LLVM-Program-Integrity.pdf">Slides</a><br><a href="https://youtu.be/isHCLMrXPUk">Video</a></td><td><b><a href="#talk23">Using LLVM to guarantee program integrity </a></b><br>Simon Cook</td></tr>
</table>
<br>
<div class="www_sectiontitle" id="abstracts">Talk Abstracts</div>
@@ -156,16 +156,16 @@ for future announcements and to ask ques
<b><a id="talk1">ORC -- LLVM's Next Generation of JIT API
</a></b><br>
<i>Lang Hames</i><br>
-<a href=âSlides/Hames-ORC.pdf">Slides</a><br>
+<a href="Slides/Hames-ORC.pdf">Slides</a><br>
<a href="https://youtu.be/hILdR8XRvdQ">Video</a><br>
-ORC is a modular re-implementation of MCJIT that allows for more flexible configuration, better memory management, more fine-grained testing, and easier addition of new features. Its feature set includes of all MCJITâs current functionality, plus built-in support for lazy and remote compilation. This talk describes ORCâs current features and design concepts, and provides demonstrations of how it can be used.
+ORC is a modular re-implementation of MCJIT that allows for more flexible configuration, better memory management, more fine-grained testing, and easier addition of new features. Its feature set includes of all MCJIT's current functionality, plus built-in support for lazy and remote compilation. This talk describes ORC's current features and design concepts, and provides demonstrations of how it can be used.
</p>
<p>
<b><a id="talk2">Causes of Performance Instability due to Code Placement in X86
</a></b><br>
<i>Zia Ansari</i><br>
-<a href=âSlides/Ansari-Code-Alignment.pdf>Slides</a><br>
+<a href="Slides/Ansari-Code-Alignment.pdf">Slides</a><br>
<a href="https://youtu.be/IX16gcX4vDQ">Video</a><br>
Have you ever experienced significant performance swings in your application after seemingly insignificant changes? A random NOP shifting code addresses causing a 20% speedup or regression? This talk will explore some of the common and not so common architectural reasons why code placement/alignment can affect performance on older and newer x86 processors. Even though ideas will be shared on how to avoid/fix some of these issues in compilers, other very low level issues will not have good compiler solutions, but are still important to recognize for knowledge and identification purposes.
</p>
@@ -174,7 +174,7 @@ Have you ever experienced significant pe
<b><a id="talk3">Intrinsics, Metadata, and Attributes: The story continues!
</a></b><br>
<i>Hal Finkel</i><br>
-<a href=âSlides/Finkel-IntrinsicsMetadataAttributes.pdf">Slides</a><br>
+<a href="Slides/Finkel-IntrinsicsMetadataAttributes.pdf">Slides</a><br>
<a href="https://youtu.be/jII0AcgU_5c">Video</a><br>
This talk is a sequel to my talk at the 2014 LLVM Developers' Meeting, in which I discussed @llvm.assume; scoped-noalias metadata; and parameter attributes that specify pointer alignment, dereferenceability, and more. The past two years have seen changes to the metadata representation itself (e.g. distinct vs. uniqued metadata), as well as new metadata that specify pointer alignment, dereferenceability, control loop optimizations, and more. Several new attributes and intrinsics allow for more-detailed control over pointer-aliasing and control-flow properties, and new intrinsics to support masked and scatter/gather memory accesses have been added. Support for older features, such as fast-math flags and the returned attribute, have been significantly extended. I'll explain the semantics of many of these new features, their intended uses, and a few ways they shouldn't be used. Finally, I'll discuss how Clang exposes and leverages these new features to encourage the generation of higher
-performance code.
</p>
@@ -183,7 +183,7 @@ This talk is a sequel to my talk at the
<b><a id="talk4">LLVM Coroutines: Bringing resumable functions to LLVM
</a></b><br>
<i>Gor Nishanov</i><br>
-<a href=âSlides/Nishanov-LLVMCoroutines.pdf">Slides</a><br>
+<a href="Slides/Nishanov-LLVMCoroutines.pdf">Slides</a><br>
<a href="https://youtu.be/Ztr8QvMhqmQ">Video</a><br>
Though invented long time ago in 1957, coroutines are getting popular in this century. More and more languages adopt them to deal with lazily produced sequences and to simplify asynchronous programming. However, until recently, coroutines in high level languages were distinctly not a zero-overhead abstraction. We are rectifying that by adding coroutine support to LLVM that allows, finally, for high-level language to have efficient coroutines
<br>
@@ -200,7 +200,7 @@ Though coroutine support in LLVM is moti
<b><a id="talk5">Scalable Vectorization for LLVM
</a></b><br>
<i>Amara Emerson, Graham Hunter</i><br>
-<a href=âSlides/Emerson-ScalableVectorizationinLLVMIR.pdf">Slides</a><br>
+<a href="Slides/Emerson-ScalableVectorizationinLLVMIR.pdf">Slides</a><br>
<a href="https://youtu.be/0up2hJk7k94">Video</a><br>
SVE is a new vector ISA extension for AArch64 targeted at HPC applications; one major distinguishing feature is that vector registers do not have a fixed size from a compiler perspective. This talk will cover the changes made to LLVM IR to support vectorizing loops in a vector length agnostic manner, as well as improvements in vectorization enabled by the predication and gather/scatter features of the extension. See https://community.arm.com/groups/processors/blog/2016/08/22/technology-update-the-scalable-vector-extension-sve-for-the-armv8-a-architecture for more details on the architecture.
</p>
@@ -209,7 +209,7 @@ SVE is a new vector ISA extension for AA
<b><a id="talk6">Devirtualization in LLVM
</a></b><br>
<i>Piotr Padlewski</i><br>
-<a href=âSlides/Padlewski-DevirtualizationInLLVM.pdf">Slides</a><br>
+<a href="Slides/Padlewski-DevirtualizationInLLVM.pdf">Slides</a><br>
<a href="https://youtu.be/qMhV6d3B1Vk">Video</a><br>
Devirtualization - changing indirect virtual calls to direct calls is important C++ optimization.
This talk will cover past work on devirtualization including optimizations made by the frontend and by LLVM using !invariant.group and @llvm.assume intrinsic and different LTO tricks. The speaker will also cover interesting problems that he faced and the future work and ideas how to make devirtualization better.
@@ -220,7 +220,7 @@ This talk will cover past work on devirt
<b><a id="talk7">Extending LoopVectorizer towards supporting OpenMP4.5 SIMD and outer loop auto-vectorization
</a></b><br>
<i>Hideki Saito</i><br>
-<a href=âSlides/Saito-NextLevelLLVMLoopVectorizer.pdf">Slides</a><br>
+<a href="Slides/Saito-NextLevelLLVMLoopVectorizer.pdf">Slides</a><br>
<a href="https://youtu.be/XXAvdUwO7kQ">Video</a><br>
Currently, LoopVectorizer in LLVM is specialized in auto-vectorizing innermost loops. SIMD and DECLARE SIMD constructs introduced in OpenMP4.0 and enhanced in OpenMP4.5 are gaining popularity among performance hungry programmers due to the ability to specify a vectorization region much larger in scope than the traditional inner loop auto-vectorization would handle and also due to several advanced vectorizing compilers delivering impressive performance for such constructs. Hence, there is a growing interest in LLVM developer community in improving LoopVectorizer in order to adequately support OpenMP functionalities such as outer loop vectorization and whole function vectorization. In this Technical Talk, we discuss our approaches in achieving that goal through a series of incremental steps and further extending it for outer loop auto-vectorization.
</p>
@@ -230,7 +230,7 @@ Currently, LoopVectorizer in LLVM is spe
<b><a id="talk8">Loop Passes: Adding new features while reducing technical debt
</a></b><br>
<i>Mikhail Zolotukhin</i><br>
-<a href=âSlides/Zolotukhin-LoopPasses.pdf">Slides</a><br>
+<a href="Slides/Zolotukhin-LoopPasses.pdf">Slides</a><br>
<a href="https://youtu.be/AfeUG7f5UA0">Video</a><br>
This year LLVM's loop passes have been greatly improved. Along with enabling new algorithms, such as new advanced loop unrolling heuristics, some long-living problems have been addressed, which resulted in significant compile time improvements and, in general, cleaner pass pipeline. We'll talk about the journey we've done along various loop passes, share our thoughts on how to avoid in future some problems we met, and share the methodology we used to find these problems.
</p>
@@ -239,7 +239,7 @@ This year LLVM's loop passes have been g
<b><a id="talk9">rev.ng: a QEMU- and LLVM-based static binary analysis framework
</a></b><br>
<i>Alessandro Di Federico</i><br>
-<a href=âSlides/DiFederico-rev.ng.pdf">Slides</a><br>
+<a href="Slides/DiFederico-rev.ng.pdf">Slides</a><br>
<a href="https://youtu.be/5CbuU4KwBCE">Video</a><br>
rev.ng is an open-source static binary analysis framework based on QEMU
and LLVM. Its core component, revamb, is a static binary translator
@@ -269,7 +269,7 @@ is in the order of the hundreds of kilob
<b><a id="talk10">A New Architecture for Building Software
</a></b><br>
<i>Daniel Dunbar</i><br>
-<a href=âSlides/Dunbar-NewArchitectureForBuildingSoftware.pdf">Slides</a><br>
+<a href="Slides/Dunbar-NewArchitectureForBuildingSoftware.pdf">Slides</a><br>
<a href="https://youtu.be/b_T-eCToX1I">Video</a><br>
Clang was written in part to deliver fast compile times for C & C++ code. However, the traditional way C compilers integrate with build systems places many limitations on how efficiently that can be done. This talk introduces llbuild -- a new framework for building build systems -- which was designed to help solve this problem, and envisions a new architecture for compiling software which would allow us to significantly improve compilation times for large software projects.
</p>
@@ -278,7 +278,7 @@ Clang was written in part to deliver fas
<b><a id="talk11">GVN-Hoist: Hoisting Computations from Branches
</a></b><br>
<i>Aditya Kumar, Sebastian Pop</i><br>
-<a href=âSlides/Kumar-Pop-GVNHoist.pdf">Slides</a><br>
+<a href="Slides/Kumar-Pop-GVNHoist.pdf">Slides</a><br>
<a href="https://youtu.be/GB3OpqSwuUw">Video</a><br>
Code-hoisting identifies identical computations across the program and hoists
them to a common dominator so as to save code size. Although the main goal of
@@ -303,7 +303,7 @@ a result of hoisting.
<b><a id="talk12">ThinLTO: Scalable and Incremental LTO
</a></b><br>
<i>Mehdi Amini, Teresa Johnson</i><br>
-<a href=âSlides/Amini-Johnson-ThinLTO.pdf">Slides</a><br>
+<a href="Slides/Amini-Johnson-ThinLTO.pdf">Slides</a><br>
<a href="https://youtu.be/9OIEZAj243g">Video</a><br>
ThinLTO was first introduced at EuroLLVM 2015 as "A Fine-Grained Demand-Driven Infrastructure". The presentation was based on an early prototype made as a proof-of-concept. Taking this original concept, we redesign it from scratch in LLVM by extending the bitcode format, redesigning the high-level workflow to remove the "demand-driven" iterative part, and adding new capabilities such as the incremental build support. We added supports in two linkers: Gold on Linux and ld64 on Darwin.
<br>
@@ -314,7 +314,7 @@ We propose in this presentation to go th
<b><a id="talk13">Killing poison and undef -- long live poison!
</a></b><br>
<i>Juneyoung Lee, Nuno Lopes</i><br>
-<a href=âSlides/Lopes-LongLivePoison.pdf">Slides</a><br>
+<a href="Slides/Lopes-LongLivePoison.pdf">Slides</a><br>
<a href="https://youtu.be/_-3Iiads1EM">Video</a><br>
The current concept of poison in LLVM is known to be broken, leaving LLVM in a state where certain miscompilation bugs are hard or even impossible to fix. Moreover, the concepts of poison and undef values in LLVM are hard to reason about and are often misunderstood by developers.
<br>
@@ -329,7 +329,7 @@ This talk is meant to increase awareness
<b><a id="talk14">Leveraging Intermediate Forms for Analysis
</a></b><br>
<i>Jared Carlson, Ayal Spitz</i><br>
-<a href=âSlides/Carlson-LeveragingIntermediateForms.pdf">Slides</a><br>
+<a href="Slides/Carlson-LeveragingIntermediateForms.pdf">Slides</a><br>
<a href="https://youtu.be/_xMUP09hmeM">Video</a><br>
In this presentation we will discuss and demonstrate an approach to build various Formal Methods (FM) tools leveraging LLVM. FM has seen a significant increase in usage in software over the past decade, being used in critical system design, security, and prototyping. We will discuss the benefits and drawbacks of LLVM IR for FM and the need for an Abstract Representation (AR) that allows for the analysis via engineering approximations. In particular we want to talk about our approach and tools that mapped our chosen AR, developed at NASA, and then extending our initial set of analysis into more logical and hierarchal relationship. Lastly we want to present what we feel are the difficulties, future challenges and successes of FM tools integrating with LLVM community.
</p>
@@ -338,7 +338,7 @@ In this presentation we will discuss and
<b><a id="talk15">Compiler-assisted Performance Analysis
</a></b><br>
<i>Adam Nemet</i><br>
-<a href=âSlides/Nemet-Compiler-assistedPerformanceAnalysis.pdf">Slides</a><br>
+<a href="Slides/Nemet-Compiler-assistedPerformanceAnalysis.pdf">Slides</a><br>
<a href="https://youtu.be/qq0q1hfzidg">Video</a><br>
Optimization diagnostics have been part of LLVM for years. While important, these diagnostics had a narrow focus on providing user feedback on the success or failure of Auto-vectorization. This work explores the possibility of extending on this foundation in order to build up a full-fledged performance analysis tool set using the compiler. The talk will first lay out the elements of this tool set. Then we will evaluate and refine it through an exploration of real- world use cases.
</p>
@@ -347,7 +347,7 @@ Optimization diagnostics have been part
<b><a id="talk16">Global Instruction Selection Status
</a></b><br>
<i>Ahmed Bougacha, Quentin Colombet, Tim Northover</i><br>
-<a href=âSlides/Colombet-GlobalISel.pdf">Slides</a><br>
+<a href="Slides/Colombet-GlobalISel.pdf">Slides</a><br>
<a href="https://youtu.be/6tfb344A7w8">Video</a><br>
Last year we presented a proposal to bring up a new instruction
selection framework, GlobalISel, in LLVM. This talk will show the progress made with the design and implementation of that proposal as well as pointing out the areas that need to be develop.
@@ -359,7 +359,7 @@ As a backend developer, you will learn w
<b><a id="talk17">Dealing with Register Hierarchies
</a></b><br>
<i>Matthias Braun</i><br>
-<a href=âSlides/Braun-DealingWithRegisterHierarchies.pdf">Slides</a><br>
+<a href="Slides/Braun-DealingWithRegisterHierarchies.pdf">Slides</a><br>
<a href="https://youtu.be/-TV77T1R7OU">Video</a><br>
Many architectures allow addressing parts of a register independently. Be it
the infamous high/low 8 bit registers of X86, the 32/64bit addressing modes of
@@ -379,7 +379,7 @@ model them and explains the register all
<b><a id="talk18">CodeView, the Microsoft Debug Info Format, in LLVM
</a></b><br>
<i>Reid Kleckner</i><br>
-<a href=âSlides/Kleckner-CodeViewInLLVM.pdf">Slides</a><br>
+<a href="Slides/Kleckner-CodeViewInLLVM.pdf">Slides</a><br>
<a href="https://youtu.be/5twzd06NqGU">Video</a><br>
The number one piece of feedback we've heard from Windows users of Clang is that they want to be able to debug their programs in Visual Studio. More than that, though, there is a world of Windows tools, such as profilers, post-mortem crash analyzers, self-debugging tools (dbghelp), and symbol servers, that makes it really worth implementing CodeView support in LLVM. Since the last dev meeting, we've been hard at work studying the format and slowly adding support for it to LLVM. This talk will give an overview of the format, and then go back and focus on the aspects that most impacted our design decisions in Clang and LLVM. As others in the community have discovered while working on LTO, LLDB, modules, and llvm-dsymutil, type information can often end up being the dominating factor in the performance of the toolchain. CodeView has some interesting design choices for solving that problem that I will share. I will close by talking about where we want to go in the future, and how we wil
l eventually use LLD to package our CodeView into a PDB file.
</p>
@@ -388,7 +388,7 @@ The number one piece of feedback we've h
<b><a id="talk19">Summary-based inter-unit analysis for Clang Static Analyzer
</a></b><br>
<i>Aleksei Sidorin</i><br>
-<a href=âSlides/Sidorin-Summery-Based-Inter-Unit-Analysis.pdf">Slides</a><br>
+<a href="Slides/Sidorin-Summery-Based-Inter-Unit-Analysis.pdf">Slides</a><br>
<a href="https://youtu.be/jbLkZ82mYE4">Video</a><br>
The ability to perform interprocedural analysis is one of the most powerful features of Clang Static Analyzer. This talk is devoted to the ongoing improvement of this feature. We will discuss our implementation of summary-based interprocedural analysis as well as cross translation unit analysis. These features allow faster analysis with a greater number of potentially found bugs. We are going to describe our implementation details and approaches and discuss their pros and cons.
</p>
@@ -397,7 +397,7 @@ The ability to perform interprocedural a
<b><a id="talk20">Developing and Shipping Clang with CMake
</a></b><br>
<i>Chris Bieneman</i><br>
-<a href=âSlides/Bieneman-CMake.pdf">Slides</a><br>
+<a href="Slides/Bieneman-CMake.pdf">Slides</a><br>
<a href="https://youtu.be/StF77Cx7pz8">Video</a><br>
In LLVM 3.8 the autoconf build system was deprecated and it was removed in favor of the newer CMake system starting in 3.9. This talk provides a brief introduction to the CMake programming language to ensure everyone basic familiarity. It will include a post-mortem on the LLVM autoconf->CMake transition, and discuss some of the useful features of the LLVM CMake build system which can improve developer productivity. We will explore a case study on packaging and shipping an LLVM toolchain with CMake including an in-depth explanation of many of the new features of the LLVM CMake build system. Lastly it will provide a status report of the current state of the build system as well as presenting some of the future improvements on the horizon.
</p>
@@ -406,7 +406,7 @@ In LLVM 3.8 the autoconf build system wa
<b><a id="talk21">Reducing Code Size Using Outlining
</a></b><br>
<i>Jessica Paquette</i><br>
-<a href=âSlides/Paquette-Outliner.pdf">Slides</a><br>
+<a href="Slides/Paquette-Outliner.pdf">Slides</a><br>
<a href="https://youtu.be/yorld-WSOeU">Video</a><br>
Maintaining a low code size overhead is important in computing domains where memory is a scarce resource. Outlining is an optimization which identifies similar regions of code and replaces them with calls to a function. This talk introduces a novel method of compressing code using an interprocedural outliner on LLVM MIR.
</p>
@@ -415,7 +415,7 @@ Maintaining a low code size overhead is
<b><a id="talk22">Toy programming demo of a repository for statically compiled programs
</a></b><br>
<i>Paul Bowen-Huggett</i><br>
-<a href=âSlides/Bowen-Hugett-ToyProgrammingDemo.pdf">Slides</a><br>
+<a href="Slides/Bowen-Hugett-ToyProgrammingDemo.pdf">Slides</a><br>
<a href="https://youtu.be/-pL94rqyQ6c">Video</a><br>
This talk will present a proof of concept of an approach which improves compile and link times by replacing the conventional use of object files with an incrementally updated repository without requiring change to existing build infrastructure. It aims to present the idea at a high-level using a live demo of some trivial tools and initiate discussion of a real implementation within the LLVM framework.
</p>
@@ -424,15 +424,15 @@ This talk will present a proof of concep
<b><a id="talk23">Using LLVM to guarantee program integrity
</a></b><br>
<i>Simon Cook</i><br>
-<a href=âSlides/Cook-LLVM-Program-Integrity.pdf">Slides</a><br>
+<a href="Slides/Cook-LLVM-Program-Integrity.pdf">Slides</a><br>
<a href="https://youtu.be/isHCLMrXPUk">Video</a><br>
There are many embedded systems on which we rely heavily in our day to day lives, and for these it is crucial to ensure that these systems are as robust as possible. To this end, it is important to have strong guarantees about the integrity of running code. Achieving this naturally requires close integration between hardware features and compiler toolchain support for these features.
<br>
-To achieve this, an NXP architecture uses hardware signing to ensure integrity of a program's control flow from modification. Each instruction's interpretation depends on the preceding instruction in the execution flow (and hence the sequence of all preceding instructions). Basic blocks require a âcorrection value" to bring the system into a consistent state when arriving from different predecessors. Compiler support is needed for this such that compiled code can receive the benefits of this feature.
+To achieve this, an NXP architecture uses hardware signing to ensure integrity of a program's control flow from modification. Each instruction's interpretation depends on the preceding instruction in the execution flow (and hence the sequence of all preceding instructions). Basic blocks require a "correction value" to bring the system into a consistent state when arriving from different predecessors. Compiler support is needed for this such that compiled code can receive the benefits of this feature.
<br>
Over the past year we have implemented the infrastructure for this feature which can be enabled on a per-function level in LLVM, for functions written in both C and/or assembly. In this talk we will present this system, and show how it enforces control flow integrity.
<br>
-We will explain how we have extended our targetâs backend with a pass that produces metadata describing a systemâs control flow. This allows branches and calls to be resolved with appropriate correction values. A particular challenge is dealing with function pointers and hence indirect transfers of control. We will also describe the implementation of user attributes to support such functionality in Clang.
+We will explain how we have extended our target's backend with a pass that produces metadata describing a system's control flow. This allows branches and calls to be resolved with appropriate correction values. A particular challenge is dealing with function pointers and hence indirect transfers of control. We will also describe the implementation of user attributes to support such functionality in Clang.
<br>
The encoding of each instruction, and the correction values cannot be finally determined until the final programs is linked. Using the metadata generated by LLVM, we can recreate the control flow graph for the entire program. From this, each instruction can be signed, and the correction values for each basic block inserted into the binary.
<br>
More information about the llvm-commits
mailing list