The snoot pass should be further modified to support the qvar construct, and support use of the extern type modifier so as to permit qvar and qint declarations and not just definitions. Once that is done, then the implemented clever compiler could in theory support multiple source code files. However, the SUIF compiler system itself at the current time only has limited support for multiple source files. In particular, version 1.0.1 does not have a supported, functional linksuif pass which would make the global symbol tables of multiple SUIF files consistent, among other things making declarations which ought to be globally visible available in all global symbol tables.
Chapter 
specifies that if there are no
qinfluence statements referencing a particular qint parameter,
then that qint parameter should be associated with the
performance of all parts of the program where the definition is
visible. This has not yet been implemented. However, this is not a
major problem but rather a minor convenience for the programmer.
The select_alternatives pass currently does not perform any kind
of smart searching of program version space, and simply searches the
entire space. It needs to incorporate both standard space searching
techniques and domain-specific heuristics enabled by the information
gathered by integrate. The current integrate pass only
finds and records relationships between qif variables which are
used in the same qif statement and qint parameters which
are referenced in nested qinfluence statements. A more
sophisticated integrate would record relationships between sets
of quasistatic variables and sets of quasistatic parameters resulting
from qinfluence statements nested inside qif clauses and
qif statements nested in qinfluence statements as well as
other qif statements. In addition, integrate should
record dynamic interactions such as in
Figure .
A given run of the program has a great deal of context which can be detected by instrumentation code in the program --- a few examples of such context items include time of day, identity of person using the program, exactly which machine is being used, load of machine during the program run, network bandwidth and latency, command-line parameters. Some of these context items may be worth storing with more standard forms of profiling data during each run, to give the clever compiler more information upon which to base program version selection. Determination of whether this would be worthwhile is a matter for pragmatic exploration.
Combining real-time profiling techniques with CPU-time profiling techniques potentially gives additional synergistic insight into a program's performance characteristics. This may be worth exploring independently of the clever compiler implementation.
A clever compiler, which requires extending the C language with new
syntax and constructs, may or may not be the best stepping stone
toward a smart compiler. However, even in developing the examples in
Chapter , several times the syntax and
constructs defined in Chapter proved to not
be sufficiently expressive to conveniently encode the code
alternatives. Perhaps a few simple extensions would suffice; however,
perhaps entirely different mechanisms of encoding code alternatives in
source code should be considered and evaluated.
It will be desireable to eventually integrate work on this clever compiler implementation with other manifestations of quasistatic computing ideas, such as feedback-directed specialization of C []. Integration might entail coordinating profiling efforts (i.e., standardizing data collection) and preventing different modules which wish to conduct experiments on different program versions from interfering with each other. Work on such integration would be a step toward a quasistatic computing ``environment'' [,].