README.html - platform/frameworks/compile/libbcc - Gitiles

 <?xml version="1.0" encoding="utf-8" ?>
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
 <meta name="generator" content="Docutils 0.6: http://docutils.sourceforge.net/" />
 <title>libbcc: A Versatile Bitcode Execution Engine for Mobile Devices</title>
 <style type="text/css">

 /*
 :Author: David Goodger (goodger@python.org)
 :Id: $Id: html4css1.css 5951 2009-05-18 18:03:10Z milde $
 :Copyright: This stylesheet has been placed in the public domain.

 Default cascading style sheet for the HTML output of Docutils.

 See http://docutils.sf.net/docs/howto/html-stylesheets.html for how to
 customize this style sheet.
 */

 /* used to remove borders from tables and images */
 .borderless, table.borderless td, table.borderless th {
   border: 0 }

 table.borderless td, table.borderless th {
   /* Override padding for "table.docutils td" with "! important".
      The right padding separates the table cells. */
   padding: 0 0.5em 0 0 ! important }

 .first {
   /* Override more specific margin styles with "! important". */
   margin-top: 0 ! important }

 .last, .with-subtitle {
   margin-bottom: 0 ! important }

 .hidden {
   display: none }

 a.toc-backref {
   text-decoration: none ;
   color: black }

 blockquote.epigraph {
   margin: 2em 5em ; }

 dl.docutils dd {
   margin-bottom: 0.5em }

 /* Uncomment (and remove this text!) to get bold-faced definition list terms
 dl.docutils dt {
   font-weight: bold }
 */

 div.abstract {
   margin: 2em 5em }

 div.abstract p.topic-title {
   font-weight: bold ;
   text-align: center }

 div.admonition, div.attention, div.caution, div.danger, div.error,
 div.hint, div.important, div.note, div.tip, div.warning {
   margin: 2em ;
   border: medium outset ;
   padding: 1em }

 div.admonition p.admonition-title, div.hint p.admonition-title,
 div.important p.admonition-title, div.note p.admonition-title,
 div.tip p.admonition-title {
   font-weight: bold ;
   font-family: sans-serif }

 div.attention p.admonition-title, div.caution p.admonition-title,
 div.danger p.admonition-title, div.error p.admonition-title,
 div.warning p.admonition-title {
   color: red ;
   font-weight: bold ;
   font-family: sans-serif }

 /* Uncomment (and remove this text!) to get reduced vertical space in
    compound paragraphs.
 div.compound .compound-first, div.compound .compound-middle {
   margin-bottom: 0.5em }

 div.compound .compound-last, div.compound .compound-middle {
   margin-top: 0.5em }
 */

 div.dedication {
   margin: 2em 5em ;
   text-align: center ;
   font-style: italic }

 div.dedication p.topic-title {
   font-weight: bold ;
   font-style: normal }

 div.figure {
   margin-left: 2em ;
   margin-right: 2em }

 div.footer, div.header {
   clear: both;
   font-size: smaller }

 div.line-block {
   display: block ;
   margin-top: 1em ;
   margin-bottom: 1em }

 div.line-block div.line-block {
   margin-top: 0 ;
   margin-bottom: 0 ;
   margin-left: 1.5em }

 div.sidebar {
   margin: 0 0 0.5em 1em ;
   border: medium outset ;
   padding: 1em ;
   background-color: #ffffee ;
   width: 40% ;
   float: right ;
   clear: right }

 div.sidebar p.rubric {
   font-family: sans-serif ;
   font-size: medium }

 div.system-messages {
   margin: 5em }

 div.system-messages h1 {
   color: red }

 div.system-message {
   border: medium outset ;
   padding: 1em }

 div.system-message p.system-message-title {
   color: red ;
   font-weight: bold }

 div.topic {
   margin: 2em }

 h1.section-subtitle, h2.section-subtitle, h3.section-subtitle,
 h4.section-subtitle, h5.section-subtitle, h6.section-subtitle {
   margin-top: 0.4em }

 h1.title {
   text-align: center }

 h2.subtitle {
   text-align: center }

 hr.docutils {
   width: 75% }

 img.align-left, .figure.align-left{
   clear: left ;
   float: left ;
   margin-right: 1em }

 img.align-right, .figure.align-right {
   clear: right ;
   float: right ;
   margin-left: 1em }

 .align-left {
   text-align: left }

 .align-center {
   clear: both ;
   text-align: center }

 .align-right {
   text-align: right }

 /* reset inner alignment in figures */
 div.align-right {
   text-align: left }

 /* div.align-center * { */
 /*   text-align: left } */

 ol.simple, ul.simple {
   margin-bottom: 1em }

 ol.arabic {
   list-style: decimal }

 ol.loweralpha {
   list-style: lower-alpha }

 ol.upperalpha {
   list-style: upper-alpha }

 ol.lowerroman {
   list-style: lower-roman }

 ol.upperroman {
   list-style: upper-roman }

 p.attribution {
   text-align: right ;
   margin-left: 50% }

 p.caption {
   font-style: italic }

 p.credits {
   font-style: italic ;
   font-size: smaller }

 p.label {
   white-space: nowrap }

 p.rubric {
   font-weight: bold ;
   font-size: larger ;
   color: maroon ;
   text-align: center }

 p.sidebar-title {
   font-family: sans-serif ;
   font-weight: bold ;
   font-size: larger }

 p.sidebar-subtitle {
   font-family: sans-serif ;
   font-weight: bold }

 p.topic-title {
   font-weight: bold }

 pre.address {
   margin-bottom: 0 ;
   margin-top: 0 ;
   font: inherit }

 pre.literal-block, pre.doctest-block {
   margin-left: 2em ;
   margin-right: 2em }

 span.classifier {
   font-family: sans-serif ;
   font-style: oblique }

 span.classifier-delimiter {
   font-family: sans-serif ;
   font-weight: bold }

 span.interpreted {
   font-family: sans-serif }

 span.option {
   white-space: nowrap }

 span.pre {
   white-space: pre }

 span.problematic {
   color: red }

 span.section-subtitle {
   /* font-size relative to parent (h1..h6 element) */
   font-size: 80% }

 table.citation {
   border-left: solid 1px gray;
   margin-left: 1px }

 table.docinfo {
   margin: 2em 4em }

 table.docutils {
   margin-top: 0.5em ;
   margin-bottom: 0.5em }

 table.footnote {
   border-left: solid 1px black;
   margin-left: 1px }

 table.docutils td, table.docutils th,
 table.docinfo td, table.docinfo th {
   padding-left: 0.5em ;
   padding-right: 0.5em ;
   vertical-align: top }

 table.docutils th.field-name, table.docinfo th.docinfo-name {
   font-weight: bold ;
   text-align: left ;
   white-space: nowrap ;
   padding-left: 0 }

 h1 tt.docutils, h2 tt.docutils, h3 tt.docutils,
 h4 tt.docutils, h5 tt.docutils, h6 tt.docutils {
   font-size: 100% }

 ul.auto-toc {
   list-style-type: none }

 </style>
 </head>
 <body>
 <div class="document" id="libbcc-a-versatile-bitcode-execution-engine-for-mobile-devices">
 <h1 class="title">libbcc: A Versatile Bitcode Execution Engine for Mobile Devices</h1>

 <div class="section" id="introduction">
 <h1>Introduction</h1>
 <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 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 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>load from the cache file upon cache-hit.</li>
 </ul>
 </li>
 </ul>
 <p>Highlights of libbcc are:</p>
 <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><p class="first">Currently we disable Lazy JITting.</p>
 </li>
 </ul>
 </div>
 <div class="section" id="api">
 <h1>API</h1>
 <p><strong>Basic:</strong></p>
 <ul class="simple">
 <li><strong>bccCreateScript</strong> - Create new bcc script</li>
 <li><strong>bccRegisterSymbolCallback</strong> - Register the callback function for external
 symbol lookup</li>
 <li><strong>bccReadBC</strong> - Set the source bitcode for compilation</li>
 <li><strong>bccReadModule</strong> - Set the llvm::Module for compilation</li>
 <li><strong>bccLinkBC</strong> - Set the library bitcode for linking</li>
 <li><strong>bccPrepareExecutable</strong> - <em>deprecated</em> - Use bccPrepareExecutableEx instead</li>
 <li><strong>bccPrepareExecutableEx</strong> - Create the in-memory executable by either
 just-in-time compilation or cache loading</li>
 <li><strong>bccGetFuncAddr</strong> - Get the entry address of the function</li>
 <li><strong>bccDisposeScript</strong> - Destroy bcc script and release the resources</li>
 <li><strong>bccGetError</strong> - <em>deprecated</em> - Don't use this</li>
 </ul>
 <p><strong>Reflection:</strong></p>
 <ul class="simple">
 <li><strong>bccGetExportVarCount</strong> - Get the count of exported variables</li>
 <li><strong>bccGetExportVarList</strong> - Get the addresses of exported variables</li>
 <li><strong>bccGetExportFuncCount</strong> - Get the count of exported functions</li>
 <li><strong>bccGetExportFuncList</strong> - Get the addresses of exported functions</li>
 <li><strong>bccGetPragmaCount</strong> - Get the count of pragmas</li>
 <li><strong>bccGetPragmaList</strong> - Get the pragmas</li>
 </ul>
 <p><strong>Debug:</strong></p>
 <ul class="simple">
 <li><strong>bccGetFuncCount</strong> - Get the count of functions (including non-exported)</li>
 <li><strong>bccGetFuncInfoList</strong> - Get the function information (name, base, size)</li>
 </ul>
 </div>
 <div class="section" id="cache-file-format">
 <h1>Cache File Format</h1>
 <p>A cache file (denoted as *.oBCC) for libbcc consists of several sections:
 header, string pool, dependencies table, relocation table, exported
 variable list, exported function list, pragma list, function information
 table, and bcc context.  Every section should be aligned to a word size.
 Here is the brief description of each sections:</p>
 <ul class="simple">
 <li><strong>Header</strong> (MCO_Header) - The header of a cache file. It contains the
 magic word, version, machine integer type information (the endianness,
 the size of off_t, size_t, and ptr_t), and the size
 and offset of other sections.  The header section is guaranteed
 to be at the beginning of the cache file.</li>
 <li><strong>String Pool</strong> (MCO_StringPool) - A collection of serialized variable
 length strings.  The strp_index in the other part of the cache file
 represents the index of such string in this string pool.</li>
 <li><strong>Dependencies Table</strong> (MCO_DependencyTable) - The dependencies table.
 This table stores the resource name (or file path), the resource
 type (rather in APK or on the file system), and the SHA1 checksum.</li>
 <li><strong>Relocation Table</strong> (MCO_RelocationTable) - <em>not enabled</em></li>
 <li><strong>Exported Variable List</strong> (MCO_ExportVarList) -
 The list of the addresses of exported variables.</li>
 <li><strong>Exported Function List</strong> (MCO_ExportFuncList) -
 The list of the addresses of exported functions.</li>
 <li><strong>Pragma List</strong> (MCO_PragmaList) - The list of pragma key-value pair.</li>
 <li><strong>Function Information Table</strong> (MCO_FuncTable) - This is a table of
 function information, such as function name, function entry address,
 and function binary size.  Besides, the table should be ordered by
 function name.</li>
 <li><strong>Context</strong> - The context of the in-memory executable, including
 the code and the data.  The offset of context should aligned to
 a page size, so that we can mmap the context directly into memory.</li>
 </ul>
 <p>For furthur information, you may read <a class="reference external" href="include/bcc/bcc_cache.h">bcc_cache.h</a>,
 <a class="reference external" href="lib/bcc/CacheReader.cpp">CacheReader.cpp</a>, and
 <a class="reference external" href="lib/bcc/CacheWriter.cpp">CacheWriter.cpp</a> for details.</p>
 </div>
 <div class="section" id="jit-ed-code-calling-conventions">
 <h1>JIT'ed Code Calling Conventions</h1>
 <ol class="arabic">
 <li><p class="first">Calls from Execution Environment or from/to within script:</p>
 <p>On ARM, the first 4 arguments will go into r0, r1, r2, and r3, in that order.
 The remaining (if any) will go through stack.</p>
 <p>For ext_vec_types such as float2, a set of registers will be used. In the case
 of float2, a register pair will be used. Specifically, if float2 is the first
 argument in the function prototype, float2.x will go into r0, and float2.y,
 r1.</p>
 <p>Note: stack will be aligned to the coarsest-grained argument. In the case of
 float2 above as an argument, parameter stack will be aligned to an 8-byte
 boundary (if the sizes of other arguments are no greater than 8.)</p>
 </li>
 <li><p class="first">Calls from/to a separate compilation unit: (E.g., calls to Execution
 Environment if those runtime library callees are not compiled using LLVM.)</p>
 <p>On ARM, we use hardfp.  Note that double will be placed in a register pair.</p>
 </li>
 </ol>
 </div>
 </div>
 </body>
 </html>
	<?xml version="1.0" encoding="utf-8" ?>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
	<meta name="generator" content="Docutils 0.6: http://docutils.sourceforge.net/" />
	<title>libbcc: A Versatile Bitcode Execution Engine for Mobile Devices</title>
	<style type="text/css">

	/*
	:Author: David Goodger (goodger@python.org)
	:Id: $Id: html4css1.css 5951 2009-05-18 18:03:10Z milde $
	:Copyright: This stylesheet has been placed in the public domain.

	Default cascading style sheet for the HTML output of Docutils.

	See http://docutils.sf.net/docs/howto/html-stylesheets.html for how to
	customize this style sheet.
	*/

	/* used to remove borders from tables and images */
	.borderless, table.borderless td, table.borderless th {
	border: 0 }

	table.borderless td, table.borderless th {
	/* Override padding for "table.docutils td" with "! important".
	The right padding separates the table cells. */
	padding: 0 0.5em 0 0 ! important }

	.first {
	/* Override more specific margin styles with "! important". */
	margin-top: 0 ! important }

	.last, .with-subtitle {
	margin-bottom: 0 ! important }

	.hidden {
	display: none }

	a.toc-backref {
	text-decoration: none ;
	color: black }

	blockquote.epigraph {
	margin: 2em 5em ; }

	dl.docutils dd {
	margin-bottom: 0.5em }

	/* Uncomment (and remove this text!) to get bold-faced definition list terms
	dl.docutils dt {
	font-weight: bold }
	*/

	div.abstract {
	margin: 2em 5em }

	div.abstract p.topic-title {
	font-weight: bold ;
	text-align: center }

	div.admonition, div.attention, div.caution, div.danger, div.error,
	div.hint, div.important, div.note, div.tip, div.warning {
	margin: 2em ;
	border: medium outset ;
	padding: 1em }

	div.admonition p.admonition-title, div.hint p.admonition-title,
	div.important p.admonition-title, div.note p.admonition-title,
	div.tip p.admonition-title {
	font-weight: bold ;
	font-family: sans-serif }

	div.attention p.admonition-title, div.caution p.admonition-title,
	div.danger p.admonition-title, div.error p.admonition-title,
	div.warning p.admonition-title {
	color: red ;
	font-weight: bold ;
	font-family: sans-serif }

	/* Uncomment (and remove this text!) to get reduced vertical space in
	compound paragraphs.
	div.compound .compound-first, div.compound .compound-middle {
	margin-bottom: 0.5em }

	div.compound .compound-last, div.compound .compound-middle {
	margin-top: 0.5em }
	*/

	div.dedication {
	margin: 2em 5em ;
	text-align: center ;
	font-style: italic }

	div.dedication p.topic-title {
	font-weight: bold ;
	font-style: normal }

	div.figure {
	margin-left: 2em ;
	margin-right: 2em }

	div.footer, div.header {
	clear: both;
	font-size: smaller }

	div.line-block {
	display: block ;
	margin-top: 1em ;
	margin-bottom: 1em }

	div.line-block div.line-block {
	margin-top: 0 ;
	margin-bottom: 0 ;
	margin-left: 1.5em }

	div.sidebar {
	margin: 0 0 0.5em 1em ;
	border: medium outset ;
	padding: 1em ;
	background-color: #ffffee ;
	width: 40% ;
	float: right ;
	clear: right }

	div.sidebar p.rubric {
	font-family: sans-serif ;
	font-size: medium }

	div.system-messages {
	margin: 5em }

	div.system-messages h1 {
	color: red }

	div.system-message {
	border: medium outset ;
	padding: 1em }

	div.system-message p.system-message-title {
	color: red ;
	font-weight: bold }

	div.topic {
	margin: 2em }

	h1.section-subtitle, h2.section-subtitle, h3.section-subtitle,
	h4.section-subtitle, h5.section-subtitle, h6.section-subtitle {
	margin-top: 0.4em }

	h1.title {
	text-align: center }

	h2.subtitle {
	text-align: center }

	hr.docutils {
	width: 75% }

	img.align-left, .figure.align-left{
	clear: left ;
	float: left ;
	margin-right: 1em }

	img.align-right, .figure.align-right {
	clear: right ;
	float: right ;
	margin-left: 1em }

	.align-left {
	text-align: left }

	.align-center {
	clear: both ;
	text-align: center }

	.align-right {
	text-align: right }

	/* reset inner alignment in figures */
	div.align-right {
	text-align: left }

	/* div.align-center * { */
	/* text-align: left } */

	ol.simple, ul.simple {
	margin-bottom: 1em }

	ol.arabic {
	list-style: decimal }

	ol.loweralpha {
	list-style: lower-alpha }

	ol.upperalpha {
	list-style: upper-alpha }

	ol.lowerroman {
	list-style: lower-roman }

	ol.upperroman {
	list-style: upper-roman }

	p.attribution {
	text-align: right ;
	margin-left: 50% }

	p.caption {
	font-style: italic }

	p.credits {
	font-style: italic ;
	font-size: smaller }

	p.label {
	white-space: nowrap }

	p.rubric {
	font-weight: bold ;
	font-size: larger ;
	color: maroon ;
	text-align: center }

	p.sidebar-title {
	font-family: sans-serif ;
	font-weight: bold ;
	font-size: larger }

	p.sidebar-subtitle {
	font-family: sans-serif ;
	font-weight: bold }

	p.topic-title {
	font-weight: bold }

	pre.address {
	margin-bottom: 0 ;
	margin-top: 0 ;
	font: inherit }

	pre.literal-block, pre.doctest-block {
	margin-left: 2em ;
	margin-right: 2em }

	span.classifier {
	font-family: sans-serif ;
	font-style: oblique }

	span.classifier-delimiter {
	font-family: sans-serif ;
	font-weight: bold }

	span.interpreted {
	font-family: sans-serif }

	span.option {
	white-space: nowrap }

	span.pre {
	white-space: pre }

	span.problematic {
	color: red }

	span.section-subtitle {
	/* font-size relative to parent (h1..h6 element) */
	font-size: 80% }

	table.citation {
	border-left: solid 1px gray;
	margin-left: 1px }

	table.docinfo {
	margin: 2em 4em }

	table.docutils {
	margin-top: 0.5em ;
	margin-bottom: 0.5em }

	table.footnote {
	border-left: solid 1px black;
	margin-left: 1px }

	table.docutils td, table.docutils th,
	table.docinfo td, table.docinfo th {
	padding-left: 0.5em ;
	padding-right: 0.5em ;
	vertical-align: top }

	table.docutils th.field-name, table.docinfo th.docinfo-name {
	font-weight: bold ;
	text-align: left ;
	white-space: nowrap ;
	padding-left: 0 }

	h1 tt.docutils, h2 tt.docutils, h3 tt.docutils,
	h4 tt.docutils, h5 tt.docutils, h6 tt.docutils {
	font-size: 100% }

	ul.auto-toc {
	list-style-type: none }

	</style>
	</head>
	<body>
	<div class="document" id="libbcc-a-versatile-bitcode-execution-engine-for-mobile-devices">
	<h1 class="title">libbcc: A Versatile Bitcode Execution Engine for Mobile Devices</h1>

	<div class="section" id="introduction">
	<h1>Introduction</h1>
	<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 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 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>load from the cache file upon cache-hit.</li>
	</ul>
	</li>
	</ul>
	<p>Highlights of libbcc are:</p>
	<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><p class="first">Currently we disable Lazy JITting.</p>
	</li>
	</ul>
	</div>
	<div class="section" id="api">
	<h1>API</h1>
	<p><strong>Basic:</strong></p>
	<ul class="simple">
	<li><strong>bccCreateScript</strong> - Create new bcc script</li>
	<li><strong>bccRegisterSymbolCallback</strong> - Register the callback function for external
	symbol lookup</li>
	<li><strong>bccReadBC</strong> - Set the source bitcode for compilation</li>
	<li><strong>bccReadModule</strong> - Set the llvm::Module for compilation</li>
	<li><strong>bccLinkBC</strong> - Set the library bitcode for linking</li>
	<li><strong>bccPrepareExecutable</strong> - <em>deprecated</em> - Use bccPrepareExecutableEx instead</li>
	<li><strong>bccPrepareExecutableEx</strong> - Create the in-memory executable by either
	just-in-time compilation or cache loading</li>
	<li><strong>bccGetFuncAddr</strong> - Get the entry address of the function</li>
	<li><strong>bccDisposeScript</strong> - Destroy bcc script and release the resources</li>
	<li><strong>bccGetError</strong> - <em>deprecated</em> - Don't use this</li>
	</ul>
	<p><strong>Reflection:</strong></p>
	<ul class="simple">
	<li><strong>bccGetExportVarCount</strong> - Get the count of exported variables</li>
	<li><strong>bccGetExportVarList</strong> - Get the addresses of exported variables</li>
	<li><strong>bccGetExportFuncCount</strong> - Get the count of exported functions</li>
	<li><strong>bccGetExportFuncList</strong> - Get the addresses of exported functions</li>
	<li><strong>bccGetPragmaCount</strong> - Get the count of pragmas</li>
	<li><strong>bccGetPragmaList</strong> - Get the pragmas</li>
	</ul>
	<p><strong>Debug:</strong></p>
	<ul class="simple">
	<li><strong>bccGetFuncCount</strong> - Get the count of functions (including non-exported)</li>
	<li><strong>bccGetFuncInfoList</strong> - Get the function information (name, base, size)</li>
	</ul>
	</div>
	<div class="section" id="cache-file-format">
	<h1>Cache File Format</h1>
	<p>A cache file (denoted as *.oBCC) for libbcc consists of several sections:
	header, string pool, dependencies table, relocation table, exported
	variable list, exported function list, pragma list, function information
	table, and bcc context. Every section should be aligned to a word size.
	Here is the brief description of each sections:</p>
	<ul class="simple">
	<li><strong>Header</strong> (MCO_Header) - The header of a cache file. It contains the
	magic word, version, machine integer type information (the endianness,
	the size of off_t, size_t, and ptr_t), and the size
	and offset of other sections. The header section is guaranteed
	to be at the beginning of the cache file.</li>
	<li><strong>String Pool</strong> (MCO_StringPool) - A collection of serialized variable
	length strings. The strp_index in the other part of the cache file
	represents the index of such string in this string pool.</li>
	<li><strong>Dependencies Table</strong> (MCO_DependencyTable) - The dependencies table.
	This table stores the resource name (or file path), the resource
	type (rather in APK or on the file system), and the SHA1 checksum.</li>
	<li><strong>Relocation Table</strong> (MCO_RelocationTable) - <em>not enabled</em></li>
	<li><strong>Exported Variable List</strong> (MCO_ExportVarList) -
	The list of the addresses of exported variables.</li>
	<li><strong>Exported Function List</strong> (MCO_ExportFuncList) -
	The list of the addresses of exported functions.</li>
	<li><strong>Pragma List</strong> (MCO_PragmaList) - The list of pragma key-value pair.</li>
	<li><strong>Function Information Table</strong> (MCO_FuncTable) - This is a table of
	function information, such as function name, function entry address,
	and function binary size. Besides, the table should be ordered by
	function name.</li>
	<li><strong>Context</strong> - The context of the in-memory executable, including
	the code and the data. The offset of context should aligned to
	a page size, so that we can mmap the context directly into memory.</li>
	</ul>
	<p>For furthur information, you may read <a class="reference external" href="include/bcc/bcc_cache.h">bcc_cache.h</a>,
	<a class="reference external" href="lib/bcc/CacheReader.cpp">CacheReader.cpp</a>, and
	<a class="reference external" href="lib/bcc/CacheWriter.cpp">CacheWriter.cpp</a> for details.</p>
	</div>
	<div class="section" id="jit-ed-code-calling-conventions">
	<h1>JIT'ed Code Calling Conventions</h1>
	<ol class="arabic">
	<li><p class="first">Calls from Execution Environment or from/to within script:</p>
	<p>On ARM, the first 4 arguments will go into r0, r1, r2, and r3, in that order.
	The remaining (if any) will go through stack.</p>
	<p>For ext_vec_types such as float2, a set of registers will be used. In the case
	of float2, a register pair will be used. Specifically, if float2 is the first
	argument in the function prototype, float2.x will go into r0, and float2.y,
	r1.</p>
	<p>Note: stack will be aligned to the coarsest-grained argument. In the case of
	float2 above as an argument, parameter stack will be aligned to an 8-byte
	boundary (if the sizes of other arguments are no greater than 8.)</p>
	</li>
	<li><p class="first">Calls from/to a separate compilation unit: (E.g., calls to Execution
	Environment if those runtime library callees are not compiled using LLVM.)</p>
	<p>On ARM, we use hardfp. Note that double will be placed in a register pair.</p>
	</li>
	</ol>
	</div>
	</div>
	</body>
	</html>