******************************************************************************** ******************************************************************************** ******************************************************************************** To: spin-comp@cs Subject: PLDI `98 Date: Thu, 11 Sep 1997 21:57:56 PDT From: Brian Grant Here is a list of priorities drafted from my notes from the meeting, past lists on the web, and little scraps of paper on my desk. :-) Please find the web page in: /projects/unisw/DynComp/www/Internal/Documentation/DyC/Papers/PLDI98 and edit the priority list. I also put a starter abstract there to get us thinking about the direction of the paper. Feel free to begin to construct an outline there as well. I put the page in RCS. It can be viewed via a link on our internal web home page (under Hot Topics). PLEASE use "X-DiscussionList: PLDI98" in your mail header when responding to this e-mail. Otherwise, I feel like I just wrote that mail-archiving script for naught. :-) --Brian Ideas for a submission to PLDI `98 The submission deadline is 5pm CST November 7. ------------------------------------------------------------------------ Priorities What follows is a list of Things To Do for the submission. We need to prioritize the list, decide which subset to target for the submission, and which (slightly larger) subset to target for the final paper. Each of the things in the list (but not all of them!) could be finished by the deadline for the final paper, but not necessarily by the submission deadline. 1. Name for our system o My latest proposal is Sorceror, which originally stood for Statically Optimized Run-time Compiler, but doesn't necessarily have to mean anything o Previous proposals: Duchamp o Defacto name: DyC 2. Benchmarks o Find the code o Run it through the 64-bit version of Multiflow o Determine what functionality is required from our system and get help from Charlie, if required o Annotate it o Examples + Our previous benchmarks + Byte-code interpreter + New SPIN dispatcher mockup + `C benchmarks (e.g., xv) + Tempo benchmarks (e.g., FFT) + Java + OpenGL + Perl, Tcl, etc. + Andrew Certain's multi-resolution viewer 3. Regression tests o Collect past test cases and re-annotate them o Develop a more comprehensive testing suite o Dust off the script(s) 4. Instrumentation o Figure out how to use the Alpha cycle counter or another way to accurately measure user cycles o Based on what we want to claim, decide what to measure and why + Overhead (partially, to estimate benefit of optimizations we don't do) + Categorized unit boundary crossings (promotions, discordant merges, etc.) + Cache lookups + Work-list operations + Function-call overhead + Per-instruction-generated (with & without above overheads) + Speedup + Breakeven points + Amount of code reuse 5. Other Infrastructure o Oracle o Compile-time specializer (could we use Tempo?) 6. Features o Static loads o Computation of lazy branch successors o Splitting the graph for multiple divisions o Function annotations o promote_one_invalidate and explicit invalidation annotations (feature or optimization?) o cache_one o cache(n) o Global space management / global cache policies o Program-point lazy annotation o Division querying o Run-time inlining (feature or optimization?) o Data specialization (feature or optimization?) 7. Optimizations o Multiflow's inlining for apps and for GE operations o Investigate excessive spilling at trace boundaries o Load pointer and float RTCONSTs into TEMPs o Static and dynamic IGOTOs o Register actions o Reduce caching overheads + Make cache_one_unchecked a single jump + Specialize lazy entries + promote_one_invalidate and explicit invalidation annotations (feature or optimization?) + PIC-style cache lookups + Hierarchical-context-based caching o Reachability conditions o Reduce work-list overhead + Peel / partially unroll the work-list loop + Eliminate redundant copying of static variables live across unit boundaries o Reduce unit-boundary crossings + Linearization + Clustering + Single-run-time-predecessor optimizations o Run-time inlining (feature or optimization?) o Further optimize memory allocation o Eliminate redundant table-pointer construction o Overwrite jmps with brs o Eliminate branch laziness when possible o Data specialization (feature or optimization?) Other Paper Thoughts * Slant? o Dynamic-compilation system that can provide speedups for real apps written in C o Useful, practical declarative system o What functionality is required for speedups? o How fast does dynamic compilation need to be? o Are there applications of dynamic compilation outside operating systems and OOPLs? * Comparisions o How will we compare our system with others? o With statically compiled C o With `C? o With an oracle? o Java: JIT? Toba? Vortex? Abstract Here is a sample abstract that I wrote a few months ago. It has a weak slant, but no mention of contributions. Somebody munge it to make it better or replace it. We previously presented the design of a dynamic compilation system for C [PEPM97]. The system requires the user to specify what code is to be dynamically compiled and leaves most of the key cost/benefit trade-offs open to user control through declarative annotatations. From these annotations our system automatically produces light-weight specialized dynamic compilers for annotated regions of the program. In this paper, we present results in applying the system to several real programs and reflect upon which functionality was required to obtain those results and to what degree we have succeeded in making dynamic compilation both fast and effective. Outline None yet. Anyone, anyone? [Image] Last updated September 11, 1997. Brian Grant (grant@cs.washington.edu)