1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
|
<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>
<!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"><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /><title>Compiler Policy</title><meta name="generator" content="DocBook XSL Stylesheets V1.62.4" /><link rel="home" href="index.html" title="SBCL User Manual" /><link rel="up" href="compiler.html" title="Chapter2.The Compiler" /><link rel="previous" href="compiler-types.html" title="The Compiler's Handling of Types" /><link rel="next" href="open-coding.html" title="Open Coding and Inline Expansion" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Compiler Policy</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="compiler-types.html">Prev</a></td><th width="60%" align="center">Chapter2.The Compiler</th><td width="20%" align="right"><a accesskey="n" href="open-coding.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="compiler-policy"></a>Compiler Policy</h2></div></div><div></div></div><p>As of version 0.6.4, <span class="application">SBCL</span> still uses most of the <span class="application">CMU CL</span> code
for compiler policy. The <span class="application">CMU CL</span> code has many features and high-quality
documentation, but the two unfortunately do not match. So this area of
the compiler and its interface needs to be cleaned up. Meanwhile, here
is some rudimentary documentation on the current behavior of the
system.</p><p>Compiler policy is controlled by the <i class="parameter"><tt>optimize</tt></i>
declaration. The compiler supports the <span class="acronym">ANSI</span> optimization qualities,
and also an extension <i class="parameter"><tt>sb-ext:inhibit-warnings</tt></i>.</p><p>Ordinarily, when the <i class="parameter"><tt>speed</tt></i> quality is high, the
compiler emits notes to notify the programmer about its inability to
apply various optimizations. Setting
<i class="parameter"><tt>sb-ext:inhibit-warnings</tt></i> to a value at least as large as
the <i class="parameter"><tt>speed</tt></i> quality inhibits this notification. This can
be useful to suppress notes about code which is known to be
unavoidably inefficient. (For example, the compiler issues notes about
having to use generic arithmetic instead of fixnum arithmetic, which
is not helpful for code which by design supports arbitrary-sized
integers instead of being limited to fixnums.)</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>The basic functionality of the <i class="parameter"><tt>optimize
inhibit-warnings</tt></i> extension will probably be supported in all future
versions of the system, but it will probably be renamed when the
compiler and its interface are cleaned up. The current name is
misleading, because it mostly inhibits optimization notes, not
warnings. And making it an optimization quality is misleading, because
it shouldn't affect the resulting code at all. It may become a
declaration identifier with a name like
<i class="parameter"><tt>sb-ext:inhibit-notes</tt></i>, so that what's currently written
</p><pre class="programlisting">(declaim (optimize (sb-ext:inhibit-warnings 2)))</pre><p>
would become something like
</p><pre class="programlisting">(declaim (sb-ext:inhibit-notes 2))</pre><p>
</p></div><p> (In early versions of SBCL, a <i class="parameter"><tt>speed</tt></i> value of zero
was used to enable byte compilation, but since version 0.7.0, SBCL
only supports native compilation.)</p><p>When <i class="parameter"><tt>safety</tt></i> is zero, almost all runtime checking
of types, array bounds, and so forth is suppressed.</p><p>When <i class="parameter"><tt>safety</tt></i> is less than <i class="parameter"><tt>speed</tt></i>, any
and all type checks may be suppressed. At some point in the past,
<span class="application">CMU CL</span> had <a href="compiler-types.html#weakened-type-checking" title="Weakened Type Checking">a more nuanced
interpretation of this</a>. However, <span class="application">SBCL</span> doesn't support that
interpretation, and setting <i class="parameter"><tt>safety</tt></i> less than
<i class="parameter"><tt>speed</tt></i> may have roughly the same effect as setting
<i class="parameter"><tt>safety</tt></i> to zero.</p><p>The value of <i class="parameter"><tt>space</tt></i> mostly influences the
compiler's decision whether to inline operations, which tend to
increase the size of programs. Use the value <tt class="literal">0</tt> with
caution, since it can cause the compiler to inline operations so
indiscriminately that the net effect is to slow the program by causing
cache misses or swapping.</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="compiler-types.html">Prev</a></td><td width="20%" align="center"><a accesskey="u" href="compiler.html">Up</a></td><td width="40%" align="right"><a accesskey="n" href="open-coding.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">The Compiler's Handling of Types</td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top">Open Coding and Inline Expansion</td></tr></table></div></body></html>
|
