Merge branch 'three-eight' of linux.cs.tufts.edu:/r/c--/papers/dfopt into three-eight
[packages/hoopl.git] / paper / proto-response.txt
1   * We apologize for missing definitions of types, functions, and data
2     structures.  Since the submission deadline we have corrected some
3     of these faults, but regardless of whether the paper is accepted
4     we would be very grateful for a referee to point out other places
5     where information is missing.
6
7   * We need to say something about Schmidt's paper.
8
9   * We agree with reviewer #1 that our paper is about solid
10     engineering; we do not claim to have made a breakthrough.  To an
11     engineer, 'appears straightforward' is a high compliment.  In the
12     design of software and systems, one wishes always to build the
13     simplest system possible.  A simple design usually seems obvious
14     only in retrospect.  Certainly we believe that the interfaces
15     described in the paper are substantially simpler than the
16     interfaces we described in 2005, and we believe that this
17     simplification required substantial intellectual effort.  But
18     perhaps others could have adapted the 2005 paper to something
19     equally simple with less effort.
20
21   * We are sorry to have given the impression that the library is
22     conceived just to serve GHC and its intermediate language.  We
23     have worked hard to make our library polymorphic so that it can be
24     used with *any* intermediate language, provided only that the
25     language distinguishes control transfers and provides a means to
26     follow control-flow edges.  We hope soon to use the library with
27     representations of machine instructions for the various platforms
28     GHC supports.
29
30     It is true that the *implementation* of the library depends on
31     GHC's internals in a few inessential ways, of which the most
32     important is probably that it uses an efficient implementation of
33     integer maps developed by Chris Okasaki and Andy Gill.
34
35   * We're not sure what Reviewer #3 would accept as evidence for a
36     library's fitness for general purposes.  This evaluation is
37     especially important as we make no claim to theoretical novelty
38     and no claim to enable analyses that cannot be implemented using
39     other methods.  Our claim is that using our library, it is much
40     *easier* to implement analyses and transformations than it is
41     using other compiler infrastructures (e.g., SUIF or vpo, to name
42     two with which we are familiar).  In order to substantiate this
43     claim, we included examples of analyses and optimizations which
44     are already known, so that readers can compare our code with code
45     written for their favorite compiler.  
46
47     To be extra confident in the correctness of the examples, we also
48     included *only* examples which have been implemented and tested as
49     part of GHC's back end.  This decision may have influenced the
50     reviewer's impression that the library is not fit for general
51     purposes.
52
53   * Along with Reviewer #2, we felt that section 7 was not properly
54     explained.  In the process of developing a better explanation, we
55     have rewritten the dataflow engine twice.  We have also rewritten
56     every part of section 7 except the part on 'optimization fuel'.
57     It would be unfair to ask referees to evaluate this new material,
58     but we feel constrained to let the referees know that whether the
59     paper is accepted at ICFP or is submitted to another venue, the
60     section 7 in the submission they have evaluated will not appear.
61
62   * To reviewer #1: if register pressure could be approximated by,
63     e.g., the number of live variables, then it would be a
64     straightforward matter to write a dataflow pass that removes
65     redundant reloads when the number of live variables is small.  In
66     fact our back end takes the opposite approach: we optimistically
67     insert a reload of $x$ only in front of the *first* use of $x$
68     (explaining why we use dataflow and not a syntactic
69     transfomration).  If register pressure leads to a spill, $x$ might
70     be spilled preferentially because we know that that value of $x$
71     is already on the stack, and thus only a reloead is needed.  (We
72     say 'might' because our register-allocation guru, who would know
73     for sure, is on his honeymoon.)
74
75 If the paper is accepted, our priorities will be:
76
77   1. To make sure all missing definitions and explanations are
78      accounted for, so that readers can understand the code easily.
79
80   2. To provide a suitable scholarly account of the relationship with
81      Schmidt's work and with abstract interpretation more generally.
82
83   3. To work extra hard on the description of the new implementation
84      (Section 7) since that will not have been reviewed by the program
85      committee. 
86
87   4. Anything else?