Merge "Skip builtin functions for compiling libraries." into honeycomb
diff --git a/README.html b/README.html
index db49a3a..76e8dda 100644
--- a/README.html
+++ b/README.html
@@ -312,35 +312,71 @@
<p>libbcc is an LLVM bitcode execution engine that compiles the bitcode
to an in-memory executable. libbcc is versatile because:</p>
<ul class="simple">
-<li>it implements both AOT (Ahead-of-Time) and JIT (Just-in-Time) compilation.</li>
-<li>Android devices demand fast start-up time, small size, and high performance
-<em>at the same time</em>. libbcc attempts to address these design constraints.</li>
+<li>it implements both AOT (Ahead-of-Time) and JIT (Just-in-Time)
+compilation.</li>
+<li>Android devices demand fast start-up time, small size, and high
+performance <em>at the same time</em>. libbcc attempts to address these
+design constraints.</li>
+<li>it supports on-device linking. Each device vendor can supply his or
+her own runtime bitcode library (lib*.bc) that differentiates his or
+her system. Specialization becomes ecosystem-friendly.</li>
</ul>
<p>libbcc provides:</p>
<ul class="simple">
-<li>a <em>just-in-time bitcode compiler</em>, which translates the bitcode into
-machine code</li>
+<li>a <em>just-in-time bitcode compiler</em>, which translates the LLVM bitcode
+into machine code</li>
<li>a <em>caching mechanism</em>, which can:<ul>
-<li>after each compilation, serialize the in-memory executable into a cache file.
-Note that the compilation is triggered by a cache miss.</li>
+<li>after each compilation, serialize the in-memory executable into a
+cache file. Note that the compilation is triggered by a cache
+miss.</li>
<li>load from the cache file upon cache-hit.</li>
</ul>
</li>
</ul>
<p>Highlights of libbcc are:</p>
-<ul class="simple">
-<li>libbcc supports bitcode from various language frontends, such as
-RenderScript, GLSL.</li>
-<li>libbcc strives to balance between library size, launch time and
-steady-state performance:<ul>
-<li>The size of libbcc is aggressively reduced for mobile devices.
-We customize and we don't use the default Execution Engine from upstream.</li>
-<li>To reduce launch time, we support caching of binaries.</li>
-<li>For steady-state performance, we enable VFP3 and aggressive
-optimizations.</li>
+<ul>
+<li><p class="first">libbcc supports bitcode from various language frontends, such as
+RenderScript, GLSL (pixelflinger2).</p>
+</li>
+<li><p class="first">libbcc strives to balance between library size, launch time and
+steady-state performance:</p>
+<ul>
+<li><p class="first">The size of libbcc is aggressively reduced for mobile devices. We
+customize and improve upon the default Execution Engine from
+upstream. Otherwise, libbcc's execution engine can easily become
+at least 2 times bigger.</p>
+</li>
+<li><p class="first">To reduce launch time, we support caching of
+binaries. Just-in-Time compilation are oftentimes Just-too-Late,
+if the given apps are performance-sensitive. Thus, we implemented
+AOT to get the best of both worlds: Fast launch time and high
+steady-state performance.</p>
+<p>AOT is also important for projects such as NDK on LLVM with
+portability enhancement. Launch time reduction after we
+implemented AOT is signficant:</p>
+<pre class="literal-block">
+Apps libbcc without AOT libbcc with AOT
+ launch time in libbcc launch time in libbcc
+App_1 1218ms 9ms
+App_2 842ms 4ms
+Wallpaper:
+ MagicSmoke 182ms 3ms
+ Halo 127ms 3ms
+Balls 149ms 3ms
+SceneGraph 146ms 90ms
+Model 104ms 4ms
+Fountain 57ms 3ms
+</pre>
+<p>AOT also masks the launching time overhead of on-device linking
+and helps it become reality.</p>
+</li>
+<li><p class="first">For steady-state performance, we enable VFP3 and aggressive
+optimizations.</p>
+</li>
</ul>
</li>
-<li>Currently we disable Lazy JITting.</li>
+<li><p class="first">Currently we disable Lazy JITting.</p>
+</li>
</ul>
</div>
<div class="section" id="api">
diff --git a/README.rst b/README.rst
index 44f4663..98381e6 100644
--- a/README.rst
+++ b/README.rst
@@ -9,34 +9,67 @@
libbcc is an LLVM bitcode execution engine that compiles the bitcode
to an in-memory executable. libbcc is versatile because:
-* it implements both AOT (Ahead-of-Time) and JIT (Just-in-Time) compilation.
+* it implements both AOT (Ahead-of-Time) and JIT (Just-in-Time)
+ compilation.
-* Android devices demand fast start-up time, small size, and high performance
- *at the same time*. libbcc attempts to address these design constraints.
+* Android devices demand fast start-up time, small size, and high
+ performance *at the same time*. libbcc attempts to address these
+ design constraints.
+
+* it supports on-device linking. Each device vendor can supply his or
+ her own runtime bitcode library (lib*.bc) that differentiates his or
+ her system. Specialization becomes ecosystem-friendly.
libbcc provides:
-* a *just-in-time bitcode compiler*, which translates the bitcode into
- machine code
+* a *just-in-time bitcode compiler*, which translates the LLVM bitcode
+ into machine code
* a *caching mechanism*, which can:
- * after each compilation, serialize the in-memory executable into a cache file.
- Note that the compilation is triggered by a cache miss.
+ * after each compilation, serialize the in-memory executable into a
+ cache file. Note that the compilation is triggered by a cache
+ miss.
* load from the cache file upon cache-hit.
Highlights of libbcc are:
* libbcc supports bitcode from various language frontends, such as
- RenderScript, GLSL.
+ RenderScript, GLSL (pixelflinger2).
* libbcc strives to balance between library size, launch time and
steady-state performance:
- * The size of libbcc is aggressively reduced for mobile devices.
- We customize and we don't use the default Execution Engine from upstream.
+ * The size of libbcc is aggressively reduced for mobile devices. We
+ customize and improve upon the default Execution Engine from
+ upstream. Otherwise, libbcc's execution engine can easily become
+ at least 2 times bigger.
- * To reduce launch time, we support caching of binaries.
+ * To reduce launch time, we support caching of
+ binaries. Just-in-Time compilation are oftentimes Just-too-Late,
+ if the given apps are performance-sensitive. Thus, we implemented
+ AOT to get the best of both worlds: Fast launch time and high
+ steady-state performance.
+
+ AOT is also important for projects such as NDK on LLVM with
+ portability enhancement. Launch time reduction after we
+ implemented AOT is signficant::
+
+
+ Apps libbcc without AOT libbcc with AOT
+ launch time in libbcc launch time in libbcc
+ App_1 1218ms 9ms
+ App_2 842ms 4ms
+ Wallpaper:
+ MagicSmoke 182ms 3ms
+ Halo 127ms 3ms
+ Balls 149ms 3ms
+ SceneGraph 146ms 90ms
+ Model 104ms 4ms
+ Fountain 57ms 3ms
+
+ AOT also masks the launching time overhead of on-device linking
+ and helps it become reality.
* For steady-state performance, we enable VFP3 and aggressive
optimizations.