983e8b6c00
procedures with large numbers of variables:
- added pass-time tracking for pre-cpnanopass passes to compile.
compile.ss
- added inline handler for fxdiv-and-mod
cp0.ss, primdata.ss
- changed order in which return-point operations are done (adjust
sfp first, then store return values, then restore local saves) to
avoid storing return values to homes beyond the end of the stack
in cases where adjusting sfp might result in a call to dooverflood.
cpnanopass.ss, np-languages.ss
- removed unused {make-,}asm-return-registers bindings
cpnanopass.ss
- corrected the max-fv value field of the lambda produced by the
hand-coded bytevector=? handler.
cpnanopass.ss
- reduced live-pointer and inspector free-variable mask computation
overhead
cpnanopass.ss
- moved regvec cset copies to driver so they aren't copied each
time a uvar is assigned to a register. removed checks for
missing register csets, since registers always have csets.
cpnanopass.ss
- added closure-rep else clause in record-inspector-information!.
cpnanopass.ss
- augmented tree representation with a constant representation
for full trees to reduce the overhead of manipulating trees or
subtress with all bits set.
cpnanopass.ss
- tree-for-each now takes start and end offsets; this cuts the
cost of traversing and applying the action when the range of
applicable offsets is other than 0..tree-size.
cpnanopass.ss
- introduced the notion of poison variables to reduce the cost of
register/frame allocation for procedures with large sets of local
variables. When the number of local variables exceeds a given
limit (currently hardwired to 1000), each variable with a large
live range is considered poison. A reasonable set of variables
with large live ranges (the set of poison variables) is computed
by successive approximation to avoid excessive overhead. Poison
variables directly conflict with all spillables, and all non-poison
spillables indirectly conflict with all poison spillables through
a shared poison-cset. Thus poison variables cannot live in the
same location as any other variable, i.e., they poison the location.
Conflicts between frame locations and poison variables are handled
normally, which allows poison variables to be assigned to
move-related frame homes. Poison variables are spilled prior to
register allocation, so conflicts between registers and poison
variables are not represented. move relations between poison
variables and frame variables are recorded as usual, but other
move relations involving poison variables are not recorded.
cpnanopass.ss, np-languages.ss
- changed the way a uvar's degree is decremented by remove-victim!.
instead of checking for a conflict between each pair of victim
and keeper and decrementing when the conflict is found, remove-victim!
now decrements the degree of each var in each victim's conflict
set. while this might decrement other victims' degrees unnecessarily,
it can be much less expensive when large numbers of variables are
involved, since the number of conflicts between two non-poison
variables should be small due to the selection process for
(non-)poison variables and the fact that the unspillables introduced
by instruction selection should also have few conflicts. That
is, it reduces the worst-case complexity of decrementing degrees
from O(n^2) to O(n).
cpnanopass.ss
- took advice in compute-degree! comment to increment the uvars in
each registers csets rather than looping over the registers for
each uvar asking whether the register conflicts with the uvar.
cpnanopass.ss
- assign-new-frame! now zeros out save-weight for local saves, since
once they are explicitly saved and restored, they are no longer
call-live and thus have no save cost.
cpnanopass.ss
- desensitized the let-values source-caching timing test slightly
8.ms
- updated allx, bullyx patches
patch*
original commit: 3a49d0193ae57b8e31ec6a00b5b49db31a52373f
|
||
|---|---|---|
| c | ||
| csug | ||
| examples | ||
| makefiles | ||
| mats | ||
| nanopass@1f7e80bcff | ||
| release_notes | ||
| s | ||
| stex@3bd2b86cc5 | ||
| unicode | ||
| wininstall | ||
| zlib@cacf7f1d4e | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .travis.yml | ||
| bintar | ||
| BUILDING | ||
| CHARTER.md | ||
| checkin | ||
| configure | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| LOG | ||
| newrelease | ||
| NOTICE | ||
| README.md | ||
| scheme.1.in | ||
| workarea | ||
Chez Scheme is both a programming language and an implementation of that language, with supporting tools and documentation.
As a superset of the language described in the Revised6 Report on the Algorithmic Language Scheme (R6RS), Chez Scheme supports all standard features of Scheme, including first-class procedures, proper treatment of tail calls, continuations, user-defined records, libraries, exceptions, and hygienic macro expansion.
Chez Scheme also includes extensive support for interfacing with C and other languages, support for multiple threads possibly running on multiple cores, non-blocking I/O, and many other features.
The Chez Scheme implementation consists of a compiler, run-time system, and programming environment. Although an interpreter is available, all code is compiled by default. Source code is compiled on-the-fly when loaded from a source file or entered via the shell. A source file can also be precompiled into a stored binary form and automatically recompiled when its dependencies change. Whether compiling on the fly or precompiling, the compiler produces optimized machine code, with some optimization across separately compiled library boundaries. The compiler can also be directed to perform whole-program compilation, which does full cross-library optimization and also reduces a program and the libraries upon which it depends to a single binary.
The run-time system interfaces with the operating system and supports, among other things, binary and textual (Unicode) I/O, automatic storage management (dynamic memory allocation and generational garbage collection), library management, and exception handling. By default, the compiler is included in the run-time system, allowing programs to be generated and compiled at run time, and storage for dynamically compiled code, just like any other dynamically allocated storage, is automatically reclaimed by the garbage collector.
The programming environment includes a source-level debugger, a mechanism for producing HTML displays of profile counts and program "hot spots" when profiling is enabled during compilation, tools for inspecting memory usage, and an interactive shell interface (the expression editor, or "expeditor" for short) that supports multi-line expression editing.
The R6RS core of the Chez Scheme language is described in The Scheme Programming Language, which also includes an introduction to Scheme and a set of example programs. Chez Scheme's additional language, run-time system, and programming environment features are described in the Chez Scheme User's Guide. The latter includes a shared index and a shared summary of forms, with links where appropriate to the former, so it is often the best starting point.
Get started with Chez Scheme by Building Chez Scheme.
For more information see the Chez Scheme Project Page.