+-Wall -Winline -W -Wwrite-strings -Wno-unused
+</pre>
+</div>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="ci_portable_code">Write Portable Code</a>
+</div>
+
+<div class="doc_text">
+
+<p>In almost all cases, it is possible and within reason to write completely
+portable code. If there are cases where it isn't possible to write portable
+code, isolate it behind a well defined (and well documented) interface.</p>
+
+<p>In practice, this means that you shouldn't assume much about the host
+compiler, and Visual Studio tends to be the lowest common denominator.
+If advanced features are used, they should only be an implementation detail of
+a library which has a simple exposed API, and preferably be buried in
+libSystem.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+<a name="ci_rtti_exceptions">Do not use RTTI or Exceptions</a>
+</div>
+<div class="doc_text">
+
+<p>In an effort to reduce code and executable size, LLVM does not use RTTI
+(e.g. <tt>dynamic_cast<></tt>) or exceptions. These two language features
+violate the general C++ principle of <i>"you only pay for what you use"</i>,
+causing executable bloat even if exceptions are never used in the code base, or
+if RTTI is never used for a class. Because of this, we turn them off globally
+in the code.</p>
+
+<p>That said, LLVM does make extensive use of a hand-rolled form of RTTI that
+use templates like <a href="ProgrammersManual.html#isa"><tt>isa<></tt>,
+<tt>cast<></tt>, and <tt>dyn_cast<></tt></a>. This form of RTTI is
+opt-in and can be added to any class. It is also substantially more efficient
+than <tt>dynamic_cast<></tt>.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+<a name="ci_class_struct">Use of <tt>class</tt> and <tt>struct</tt> Keywords</a>
+</div>
+<div class="doc_text">
+
+<p>In C++, the <tt>class</tt> and <tt>struct</tt> keywords can be used almost
+interchangeably. The only difference is when they are used to declare a class:
+<tt>class</tt> makes all members private by default while <tt>struct</tt> makes
+all members public by default.</p>
+
+<p>Unfortunately, not all compilers follow the rules and some will generate
+different symbols based on whether <tt>class</tt> or <tt>struct</tt> was used to
+declare the symbol. This can lead to problems at link time.</p>
+
+<p>So, the rule for LLVM is to always use the <tt>class</tt> keyword, unless
+<b>all</b> members are public and the type is a C++
+<a href="http://en.wikipedia.org/wiki/Plain_old_data_structure">POD</a> type, in
+which case <tt>struct</tt> is allowed.</p>
+
+</div>
+
+<!-- *********************************************************************** -->
+<div class="doc_section">
+ <a name="styleissues">Style Issues</a>
+</div>
+<!-- *********************************************************************** -->
+
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="macro">The High-Level Issues</a>
+</div>
+<!-- ======================================================================= -->
+
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="hl_module">A Public Header File <b>is</b> a Module</a>
+</div>
+
+<div class="doc_text">
+
+<p>C++ doesn't do too well in the modularity department. There is no real
+encapsulation or data hiding (unless you use expensive protocol classes), but it
+is what we have to work with. When you write a public header file (in the LLVM
+source tree, they live in the top level "<tt>include</tt>" directory), you are
+defining a module of functionality.</p>
+
+<p>Ideally, modules should be completely independent of each other, and their
+header files should only <tt>#include</tt> the absolute minimum number of
+headers possible. A module is not just a class, a function, or a
+namespace: <a href="http://www.cuj.com/articles/2000/0002/0002c/0002c.htm">it's
+a collection of these</a> that defines an interface. This interface may be
+several functions, classes, or data structures, but the important issue is how
+they work together.</p>
+
+<p>In general, a module should be implemented by one or more <tt>.cpp</tt>
+files. Each of these <tt>.cpp</tt> files should include the header that defines
+their interface first. This ensures that all of the dependences of the module
+header have been properly added to the module header itself, and are not
+implicit. System headers should be included after user headers for a
+translation unit.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="hl_dontinclude"><tt>#include</tt> as Little as Possible</a>
+</div>
+
+<div class="doc_text">
+
+<p><tt>#include</tt> hurts compile time performance. Don't do it unless you
+have to, especially in header files.</p>
+
+<p>But wait! Sometimes you need to have the definition of a class to use it, or
+to inherit from it. In these cases go ahead and <tt>#include</tt> that header
+file. Be aware however that there are many cases where you don't need to have
+the full definition of a class. If you are using a pointer or reference to a
+class, you don't need the header file. If you are simply returning a class
+instance from a prototyped function or method, you don't need it. In fact, for
+most cases, you simply don't need the definition of a class. And not
+<tt>#include</tt>'ing speeds up compilation.</p>
+
+<p>It is easy to try to go too overboard on this recommendation, however. You
+<b>must</b> include all of the header files that you are using — you can
+include them either directly or indirectly (through another header file). To
+make sure that you don't accidentally forget to include a header file in your
+module header, make sure to include your module header <b>first</b> in the
+implementation file (as mentioned above). This way there won't be any hidden
+dependencies that you'll find out about later.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="hl_privateheaders">Keep "Internal" Headers Private</a>
+</div>
+
+<div class="doc_text">
+
+<p>Many modules have a complex implementation that causes them to use more than
+one implementation (<tt>.cpp</tt>) file. It is often tempting to put the
+internal communication interface (helper classes, extra functions, etc) in the
+public module header file. Don't do this!</p>
+
+<p>If you really need to do something like this, put a private header file in
+the same directory as the source files, and include it locally. This ensures
+that your private interface remains private and undisturbed by outsiders.</p>
+
+<p>Note however, that it's okay to put extra implementation methods in a public
+class itself. Just make them private (or protected) and all is well.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="hl_earlyexit">Use Early Exits and <tt>continue</tt> to Simplify Code</a>
+</div>
+
+<div class="doc_text">
+
+<p>When reading code, keep in mind how much state and how many previous
+decisions have to be remembered by the reader to understand a block of code.
+Aim to reduce indentation where possible when it doesn't make it more difficult
+to understand the code. One great way to do this is by making use of early
+exits and the <tt>continue</tt> keyword in long loops. As an example of using
+an early exit from a function, consider this "bad" code:</p>
+
+<div class="doc_code">
+<pre>
+Value *DoSomething(Instruction *I) {
+ if (!isa<TerminatorInst>(I) &&
+ I->hasOneUse() && SomeOtherThing(I)) {
+ ... some long code ....