Home My Page Projects Code Snippets Project Openings SML/NJ
Summary Activity Forums Tracker Lists Tasks Docs Surveys News SCM Files

SCM Repository

[smlnj] Diff of /sml/trunk/HISTORY
ViewVC logotype

Diff of /sml/trunk/HISTORY

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1098, Wed Feb 27 17:29:47 2002 UTC revision 1126, Thu Mar 7 21:16:28 2002 UTC
# Line 14  Line 14 
14    
15  ----------------------------------------------------------------------  ----------------------------------------------------------------------
16  Name: Matthias Blume  Name: Matthias Blume
17    Date: 2002/03/07 16:15:00 EST
18    Tag: blume-20020307-controls
19    Description:
20    
21    This is a very large but mostly boring patch which makes (almost)
22    every tuneable compiler knob (i.e., pretty much everything under
23    Control.* plus a few other things) configurable via both the command
24    line and environment variables in the style CM did its configuration
25    until now.
26    
27    Try starting sml with '-h' (or, if you are brave, '-H')
28    
29    To this end, I added a structure Controls : CONTROLS to smlnj-lib.cm which
30    implements the underlying generic mechanism.
31    
32    The interface to some of the existing such facilities has changed somewhat.
33    For example, the MLRiscControl module now provides mkFoo instead of getFoo.
34    (The getFoo interface is still there for backward-compatibility, but its
35    use is deprecated.)
36    
37    The ml-build script passes -Cxxx=yyy command-line arguments through so
38    that one can now twiddle the compiler settings when using this "batch"
39    compiler.
40    
41    TODO items:
42    
43    We should go through and throw out all controls that are no longer
44    connected to anything.  Moreover, we should go through and provide
45    meaningful (and correct!) documentation strings for those controls
46    that still are connected.
47    
48    Currently, multiple calls to Controls.new are accepted (only the first
49    has any effect).  Eventually we should make sure that every control
50    is being made (via Controls.new) exactly once.  Future access can then
51    be done using Controls.acc.
52    
53    Finally, it would probably be a good idea to use the getter-setter
54    interface to controls rather than ref cells.  For the time being, both
55    styles are provided by the Controls module, but getter-setter pairs are
56    better if thread-safety is of any concern because they can be wrapped.
57    
58    *****************************************
59    
60    One bug fix: The function blockPlacement in three of the MLRISC
61    backpatch files used to be hard-wired to one of two possibilities at
62    link time (according to the value of the placementFlag).  But (I
63    think) it should rather sense the flag every time.
64    
65    *****************************************
66    
67    Other assorted changes (by other people who did not supply a HISTORY entry):
68    
69    1. the cross-module inliner now works much better (Monnier)
70    2. representation of weights, frequencies, and probabilities in MLRISC
71       changed in preparation of using those for weighted block placement
72       (Reppy, George)
73    
74    ----------------------------------------------------------------------
75    Name: Lal George
76    Date: 2002/03/07 14:44:24 EST 2002
77    Tag: george-20020307-weighted-block-placement
78    
79    Tested the weighted block placement optimization on all architectures
80    (except the hppa) using AMPL to generate the block and edge frequencies.
81    Changes were required in the machine properties to correctly
82    categorize trap instructions. There is an MLRISC flag
83    "weighted-block-placement" that can be used to enable weighted block
84    placement, but this will be ineffective without block/edge
85    frequencies (coming soon).
86    
87    
88    ----------------------------------------------------------------------
89    Name: Lal George
90    Date: 2002/03/05 17:24:48 EST
91    Tag: george-20020305-linkage-cluster
92    
93    In order to support the block placement optimization, a new cluster
94    is generated as the very first cluster (called the linkage cluster).
95    It contains a single jump to the 'real' entry point for the compilation
96    unit. Block placement has no effect on the linkage cluster itself, but
97    all the other clusters  have full freedom in the manner in which they
98    reorder blocks or functions.
99    
100    On the x86 the typical linkage code that is generated is:
101       ----------------------
102            .align 2
103       L0:
104            addl    $L1-L0, 72(%esp)
105            jmp     L1
106    
107    
108            .align  2
109       L1:
110       ----------------------
111    
112    72(%esp) is the memory location for the stdlink register. This
113    must contain the address of the CPS function being called. In the
114    above example, it contains the address of  L0; before
115    calling L1 (the real entry point for the compilation unit), it
116    must contain the address for L1, and hence
117    
118            addl $L1-L0, 72(%esp)
119    
120    I have tested this on all architectures except the hppa.The increase
121    in code size is of course negligible
122    
123    ----------------------------------------------------------------------
124    Name: Allen Leung
125    Date: 2002/03/03 13:20:00 EST
126    Tag: leunga-20020303-mlrisc-tools
127    
128      Added #[ ... ] expressions to mlrisc tools
129    
130    ----------------------------------------------------------------------
131    Name: Matthias Blume
132  Date: 2002/02/27 12:29:00 EST  Date: 2002/02/27 12:29:00 EST
133  Tag: blume-20020227-cdebug  Tag: blume-20020227-cdebug
134  Description:  Description:
# Line 134  Line 249 
249         TOTAL                                   2375.26u  57.21s  48.00g         TOTAL                                   2375.26u  57.21s  48.00g
250    
251  As you can see the old cps spill module suffers from some serious  As you can see the old cps spill module suffers from some serious
252  performance problem but since I cannot decipher the old code fully,  performance problem.  But since I cannot decipher the old code fully,
253  innstead of patching the problems up, I'm reimplementing it  instead of patching the problems up, I'm reimplementing it
254  with a different algorithm.  The new code is more modular,  with a different algorithm.  The new code is more modular,
255  smaller when compiled, and substantially faster  smaller when compiled, and substantially faster
256  (O(n log n) time and O(n) space).  Timing of the new spill module:  (O(n log n) time and O(n) space).  Timing of the new spill module:

Legend:
Removed from v.1098  
changed lines
  Added in v.1126

root@smlnj-gforge.cs.uchicago.edu
ViewVC Help
Powered by ViewVC 1.0.0