Subject: publishing
From: Craig Chambers (chambers@cs.washington.edu)
Date: Wed Feb 21 2001 - 13:33:38 PST
I'm publishing some improvements to the Java front-end for Whirlwind,
and a couple of Whirlwind fixes. I'm installing a new vortex executable
(Vass, this is mainly for you), and a new whirlwind.nCCP profile.
In the Java front-end:
*) I changed the Jil-em script and the jil Java front-end so that each
.wil file explicitly includes those other .wil files that it directly
depends on (i.e., whose classes or GFs or fns or static vars it
directly references). The top-level Jil-em-generated file just
includes the main class's .wil file. The extent of the application is
determined solely by the transitive closure of these direct depends-on
relations, rather than forcing the top-level .wil file to explicitly
include all the classes in the application. The Files file still
exists, but it is used just to give a list of files to translate. It
must include all files in the program, but it can overestimate without
bloating the application. This is especially useful for the standard
library classes, since we now can freely translate all files in the
library, and still have each application only include those files that
it actually references, directly or indirectly.
As an example, towers now comprises 101 files, down from 178. The
empty program is about 90 files.
*) I translated all 4273 SDK 1.2.1 library classes through Jil.
Towers using this stdlib comprises a whopping 589 files. I've added
these translated files to the CVS repository, under
.../vortex/Java/wil-stdlib-SDK.
*) In order to get rid of the main file for libraries, I changed how
array classes are declared, eliminating the global .arrays.wil file
that Jil-em used to generate, and replacing it with each file adding
once declarations for the array classes they need. These are the
first once declarations produced by the Java front-end, and we'll have
to get Whirlwind to generate compilable C code for them. (Whirlwind
runs fine on the new Java .wil files, it just doesn't generate C code
that works. But that's always been true about Whirlwind.)
*) I separated JV-em and Jil-em. Both JV-em and especially Jil-em
have been cleaned up after the split. I renamed some Jil-em input
files, e.g. ClassDir is now Classpath, and I removed LibName,
IncludeStdlib, and UseJil from the Jil-em front-end. (If JV-em is
invoked and the UseJil file is present, then Jil-em is invoked
automatically, as a convenience in case people accidentally use the
old name.)
*) I discovered a nasty bug in the Java front-end, where it was not
properly weaking some inferred information about local and stack
variables at merge points in the bytecode. (To simply their output,
both the Vortex and Whirlwind Java front-ends do a simple kind of
dataflow propagation, within basic blocks.) I fixed this bug in both
front-ends, although it didn't change the output of the Vortex Java
front-end on any of the standard library classes or benchmarks, so
maybe it wasn't a real bug in the Vortex Java front-end for some
reason. It certainly was a problem in the Whirlwind Java front-end.
*) I implemented an optimization in the Whirlwind Java front-end where
the call to check for initialization of a class is omitted from
references within that class (since the class necessarily has already
been initialized).
--------------------------------
In Whirlwind:
*) For some reason, the call during CFG construction to link nodes to
their exception handlers got deleted in a recent publish. So no
exception control edges were ever taken. This caused cfg graph
verification to complain on one of the SDK library classes, but it's
completely incorrect semantically for all other files, too. I put the
call back in. (FYI, I used CVSWeb to locate the problem and find out
what the original code used to be. A very cool way to browse revision
diffs!)
*) I fixed a bug in Whirlwind, discovered when trying to compile
towers with the SDK 1.2.1 stdlib, relating to lowering of var & rep
decls. Now, lowering of decls is done by walking through the scope,
not as part of traversing IR nodes. Lowering of global decls is done
similarly via the scope rather than traversing all files. The
WindGlobalsLowered slice was removed.
*) I fixed a problem when constructing the DFG for global references
to global initial variables defined in other files (or later in the
same file). They used to be replaced with top (undefined) dataflow
sources. Now I leave them as variable reference nodes.
*) I modified the rep checking & computing passes so that they are now
unforgiving in the face of missing narrows and some other kinds of rep
checking errors. This reflects the assumptions of the rest of the
compiler that rep-checked IRs have correct reps associated with all
nodes. I removed the ErrorRep object.
*) I added some quotes to arguments of system() calls, to avoid
treating $ as shell meta-characters. $ can appear in filenames,
e.g. for .wil files coming from Java inner classes. We might even be
able to handle other meta-characters in filenames, aside from
single-quote itself. You need to include this change in your
Whirlwind executable if you start using the new SDK-1.2.1 stdlib
files.
*) I fixed a problem in Whirlwind where there were a few lingering
references to .local.h generated files. These have all been renamed
to plain .h files now.
*) I improved Whirlwind's typecheck command so that it remembers which
files have been fully typechecked, and only re-typechecks those that
have been changed or invalidated in some way since the last time the
files were typechecked. I created a WindRepsComputedRecursively slice
to record which IRs have had all their nested IRs
rep-computed/-checked.
*) I added a "makeonly" command to Whirlwind. This command takes a
list of file names (e.g. java.lang.Integer.class.wil) and recompiles
just those files (ignoring whether they're out of date or not). This
is handy when testing out the compiler on a particularly troublesome
file or two. makeonly also can have a o0, o1, or o2 suffix, to force
compilation at a particular optimization level.
*) I sped up the simple DFG building pass (used when compiling w/o
optimization) by omitting building tables of declared variables, which
were never used by the simple pass but incur a lot of overhead. Now
the simple DFG construction pass takes 31secs of the overall 280secs
of compilation of towers (with the 1.0.2 stdlib). By contrast, w/
optimization on, the fancier DFG construction pass takes 97secs of the
overall 564secs of compilation time, which is the largest single
component. [Incidentally, I don't think phase times are being
gathered for the optimization passes people have added,
e.g. constant-prop. This should be fixed.]
*) I added a print_compilation_progress option, which prints something
out at the start of compiling each file or function IR node.
*) I changed the graph printing code to always use the DFG for
dataflow edges if the DFG has been constructed, and to use the AST
otherwise.
*) I removed some old entries from the Whirlwind help output.
--------------------------------
Test summary:
Whirlwind typechecks and compiles, w/ and w/o optimization towers
against the 1.0.2 stdlib (the standard one), and typechecks and
compiles w/o optimization against the 1.2.1 stdlib (the new one).
Towers doesn't finish compiling w/ optimization against the 1.2.1
stdlib, dying with an out-of-memory error. I don't know if this is a
bug, or just that resources have overflowed. Also, the towers.db
checkpoint for towers against the 1.2.1 stdlib is a whopping 244MB
big, which leads me to believe that we have some sort of space leak in
our checkpoint writing and/or AST compression, or at least that our
current approach to storing top-level ASTs is infeasible for bigger
programs. And I'm getting some weird messages about various tables
growing during the objectIO.c checkpoint writing primitive that make
me nervous that there's some sort of problem. So there is some more
work to be done to get Whirlwind able to handle the bigger stdlib.
-- Craig
_______________________________________________
Cecil mailing list
Cecil@cs.washington.edu
http://majordomo.cs.washington.edu/mailman/listinfo/cecil
This archive was generated by hypermail 2b25 : Wed Feb 21 2001 - 13:34:05 PST