suzanne.soy/racket
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update bytecode compiler/optimizer overview in source comments

Browse Source 
Explain the recently added "letrec_check" pass.
This commit is contained in:
Matthew Flatt 2014-05-31 13:28:47 +01:00
parent 1558e1243a
commit 9d94ef725e
1 changed files with 16 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
racket/src/racket/src/eval.c
View File

@ -87,11 +87,18 @@
tracks variable usage (including whether a variable is mutated or tracks variable usage (including whether a variable is mutated or
not). See "compile.c" along with "compenv.c". not). See "compile.c" along with "compenv.c".
The second pass, called "optimize", performs constant propagation, The second pass, called "letrec_rec", determines which references
constant folding, and function inlining; this pass mutates records to `letrec'-bound variables need to be guarded with a run-time
produced by the first pass. See "optimize.c". check to prevent use before definition. The analysis result is
reflected by the insertion of `check-notunsafe-undefined`
calls. This this pass mutates records produced by the "compile"
pass.
The third pass, called "resolve", finishes compilation by computing The third pass, called "optimize", performs constant propagation,
constant folding, and function inlining; this pass mutates records
produced by the "letrec_check" pass. See "optimize.c".
The fourth pass, called "resolve", finishes compilation by computing
variable offsets and indirections (often mutating the records variable offsets and indirections (often mutating the records
produced by the first pass). It is also responsible for closure produced by the first pass). It is also responsible for closure
conversion (i.e., converting closure content to arguments) and conversion (i.e., converting closure content to arguments) and
@ -100,7 +107,7 @@
due to sharing (potentially cyclic) of closures that are "empty" due to sharing (potentially cyclic) of closures that are "empty"
but actually refer to other "empty" closures. See "resolve.c". but actually refer to other "empty" closures. See "resolve.c".
The fourth pass, "sfs", performs another liveness analysis on stack The fifth pass, "sfs", performs another liveness analysis on stack
slots and inserts operations to clear stack slots as necessary to slots and inserts operations to clear stack slots as necessary to
make execution safe for space. In particular, dead slots need to be make execution safe for space. In particular, dead slots need to be
cleared before a non-tail call into arbitrary Racket code. This pass cleared before a non-tail call into arbitrary Racket code. This pass
@ -118,8 +125,10 @@
Just-in-time compilation: Just-in-time compilation:
If the JIT is enabled, then `eval' processes (perhaps unmarshaled If the JIT is enabled, then an extra "jitprep" pass processes
and validated) bytecode one more time: `lambda' and `case-lambda' bytecode one more time --- but only bytecode that is not going to
be marshaled, and possibly bytecode that was just unmarshaled.
In this "jitprep" pass, the `lambda' and `case-lambda'
forms are converted to native-code generators, instead of bytecode forms are converted to native-code generators, instead of bytecode
variants. The code is not actually JITted until it is called; this variants. The code is not actually JITted until it is called; this
preparation step merely sets up a JIT hook for each function. The preparation step merely sets up a JIT hook for each function. The