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 1069, Fri Feb 15 21:00:05 2002 UTC revision 1174, Sat Mar 23 21:14:40 2002 UTC
# Line 13  Line 13 
13  Description:  Description:
14    
15  ----------------------------------------------------------------------  ----------------------------------------------------------------------
16    Name: Allen Leung
17    Date: 2002/03/23 15:50:00 EST
18    Tag: leunga-20020323-flint-cps-rcc-primops
19    Description:
20    
21      1. Changes to FLINT primops:
22    
23        (* make a call to a C-function;
24         * The primop carries C function prototype information and specifies
25         * which of its (ML-) arguments are floating point. C prototype
26         * information is for use by the backend, ML information is for
27         * use by the CPS converter. *)
28      | RAW_CCALL of { c_proto: CTypes.c_proto,
29                       ml_args: ccall_type list,
30                       ml_res_opt: ccall_type option,
31                       reentrant : bool
32                     } option
33       (* Allocate uninitialized storage on the heap.
34        * The record is meant to hold short-lived C objects, i.e., they
35        * are not ML pointers.  With the tag, the representation is
36        * the same as RECORD with tag tag_raw32 (sz=4), or tag_fblock (sz=8)
37        *)
38      | RAW_RECORD of {tag:bool,sz:int}
39      and ccall_type = CCALL_INT32 | CCALL_REAL64 | CCALL_ML_PTR
40    
41      2.  These CPS primops are now overloaded:
42    
43           rawload of {kind:numkind}
44           rawstore of {kind:numkind}
45    
46          The one argument form is:
47    
48             rawload {kind} address
49    
50          The two argument form is:
51    
52             rawload {kind} [ml object, byte-offset]
53    
54      3. RAW_CCALL/RCC now takes two extra arguments:
55    
56         a. The first is whether the C call is reentrant, i.e., whether
57            ML state should be saved and restored.
58         b. The second argument is a string argument specifying the name of
59            library and the C function.
60    
61         These things are currently not handled in the code generator, yet.
62    
63      4. In CProto,
64    
65         An encoding type of "bool" means "ml object" and is mapped into
66         C prototype of PTR.  Note that "bool" is different than "string",
67         even though "string" is also mapped into PTR, because "bool"
68         is assigned an CPS type of BOGt, while "string" is assigned INT32t.
69    
70      5. Pickler/unpicker
71    
72         Changed to handle RAW_RECORD and newest RAW_CCALL
73    
74      6. MLRiscGen,
75    
76         1. Changed to handle the new rawload/rawstore/rawrecord operators.
77         2. Code for handling C Calls has been moved to a new module CPSCCalls,
78            in the file CodeGen/cpscompile/cps-c-calls.sml
79    
80      7. Added the conditional move operator
81    
82             condmove of branch
83    
84         to cps.  Generation of this is still buggy so it is currently
85         disabled.
86    
87    ----------------------------------------------------------------------
88    Name: Lal George
89    Date: 2002/03/22 14:18:25 EST
90    Tag: george-20020322-cps-branch-prob
91    Description:
92    
93    Implemented the Ball-Larus branch prediction-heuristics, and
94    incorporated graphical viewers for control flow graphs.
95    
96    Ball-Larus Heuristics:
97    ---------------------
98    See the file compiler/CodeGen/cpscompile/cpsBranchProb.sml.
99    
100    By design it uses the Dempster-Shafer theory for combining
101    probabilities.  For example, in the function:
102    
103        fun f(n,acc) = if n = 0 then acc else f(n-1, n*acc)
104    
105    the ball-larus heuristics predicts that the n=0 is unlikely
106    (OH-heuristic), and the 'then' branch is unlikely because of the
107    RH-heuristic -- giving the 'then' branch an even lower combined
108    probability using the Dempster-Shafer theory.
109    
110    Finally, John Reppy's loop analysis in MLRISC, further lowers the
111    probability of the 'then' branch because of the loop in the else
112    branch.
113    
114    
115    Graphical Viewing:
116    ------------------
117    I merely plugged in Allen's graphical viewers into the compiler. The
118    additional code is not much. At the top level, saying:
119    
120            Control.MLRISC.getFlag "cfg-graphical-view" := true;
121    
122    will display the graphical view of the control flow graph just before
123    back-patching.  daVinci must be in your path for this to work. If
124    daVinci is not available, then the default viewer can be changed
125    using:
126    
127            Control.MLRISC.getString "viewer"
128    
129    which can be set to "dot" or "vcg" for the corresponding viewers. Of
130    course, these viewers must be in your path.
131    
132    The above will display the compilation unit at the level of clusters,
133    many of which are small, boring, and un-interesting. Also setting:
134    
135            Control.MLRISC.getInt "cfg-graphical-view_size"
136    
137    will display clusters that are larger than the value set by the above.
138    
139    
140    ----------------------------------------------------------------------
141  Name: Matthias Blume  Name: Matthias Blume
142  Date: 2002/02/15 16:00:00 EST  Date: 2002/03/21 22:20:00 EST
143    Tag: blume-20020321-kmp-bugfix
144    Description:
145    
146    Changed the interface to the KMP routine in PreString and fixed
147    a minor bug in one place where it was used.
148    
149    ----------------------------------------------------------------------
150    Name: Allen Leung
151    Date: 2002/03/21 20:30:00 EST
152    Tag: leunga-20020321-cfg
153    Description:
154    
155      Fixed a potential problem in cfg edge splitting.
156    
157    ----------------------------------------------------------------------
158    Name: Allen Leung
159    Date: 2002/03/21 17:15:00 EST
160    Tag: leunga-20020321-x86-fp-cfg
161    Description:
162    
163      1. Recoded the buggy parts of x86-fp.
164    
165         a. All the block reordering code has been removed.
166            We now depend on the block placement phases to do this work.
167    
168         b. Critical edge splitting code has been simplified and moved into the
169            CFG modules, as where they belong.
170    
171         Both of these were quite buggy and complex.  The code is now much, much
172         simpler.
173    
174      2. X86 backend.
175    
176         a. Added instructions for 64-bit support.  Instruction selection for
177            64-bit has not been committed, however, since that
178            requires changes to MLTREE which haven't been approved by
179            Lal and John.
180    
181         b. Added support for FUCOMI and FUCOMIP when generating code for
182            PentiumPro and above.  We only generate these instructions in
183            the fast-fp mode.
184    
185         c. Added cases for JP and JNP in X86FreqProps.
186    
187      3. CFG
188    
189         CFG now has a bunch of methods for edge splitting and merging.
190    
191      4. Machine description.
192    
193         John's simplification of MLTREE_BASIS.fcond broke a few machine
194         description things:
195    
196         rtl-build.{sig,sml} and hppa.mdl fixed.
197    
198         NOTE: the machine description stuff in the repository is still broken.
199               Again, I can't put my fixes in because that involves
200               changes to MLTREE.
201    
202    ----------------------------------------------------------------------
203    Name: Matthias Blume
204    Date: 2002/03/20 15:55:00 EST
205    Tag: blume-20020320-kmp
206    Description:
207    
208    Implemented Knuth-Morris-Pratt string matching in PreString and used
209    it for String.isSubstring, Substring.isSubstring, and
210    Substring.position.
211    
212    (Might need some stress-testing.  Simple examples worked fine.)
213    
214    ----------------------------------------------------------------------
215    Name: Matthias Blume
216    Date: 2002/03/19 16:37:00 EST
217    Tag: blume-20020319-witnesses
218    Description:
219    
220    Added a structure C.W and functions convert/Ptr.convert to ml-nlffi-lib.
221    
222    This implements a generic mechanism for changing constness qualifiers
223    anywhere within big C types without resorting to outright "casts".
224    (So far, functions such as C.rw/C.ro or C.Ptr.rw/C.Ptr.ro only let you
225    modify the constness at the outermost level.)
226    The implementation of "convert" is based on the idea of "witness"
227    values -- values that are not used by the operation but whose types
228    "testify" to their applicability.  On the implementation side, "convert"
229    is simply a projection (returning its second curried argument).  With
230    cross-module inlining, it should not result in any machine code being
231    generated.
232    
233    ----------------------------------------------------------------------
234    Name: Matthias Blume
235    Date: 2002/03/15 16:40:00 EST
236    Tag: blume-20020315-basis
237    Description:
238    
239    Provided (preliminary?) implementations for
240    
241      {String,Substring}.{concatWith,isSuffix,isSubstring}
242    
243    and
244    
245      Substring.full
246    
247    Those are in the Basis spec but they were missing in SML/NJ.
248    
249    ----------------------------------------------------------------------
250    Name: Matthias Blume
251    Date: 2002/03/14 21:30:00 EST
252    Tag: blume-20020314-controls
253    Description:
254    
255    Controls:
256    ---------
257    
258    1. Factored out the recently-added Controls : CONTROLS stuff and put
259       it into its own library $/controls-lib.cm.  The source tree for
260       this is under src/smlnj-lib/Controls.
261    
262    2. Changed the names of types and functions in this interface, so they
263       make a bit more "sense":
264    
265          module -> registry
266          'a registry -> 'a group
267    
268    3. The interface now deals in ref cells only.  The getter/setter interface
269       is (mostly) gone.
270    
271    4. Added a function that lets one register an already-existing ref cell.
272    
273    5. Made the corresponding modifications to the rest of the code so that
274       everything compiles again.
275    
276    6. Changed the implementation of Controls.MLRISC back to something closer
277       to the original.  In particular, this module (and therefore MLRISC)
278       does not depend on Controls.  There now is some link-time code in
279       int-sys.sml that registers the MLRISC controls with the Controls
280       module.
281    
282    CM:
283    ---
284    
285      * One can now specify the lambda-split aggressiveness in init.cmi.
286    
287    ----------------------------------------------------------------------
288    Name: Allen Leung
289    Date: 2002/03/13 17:30:00 EST
290    Tag: leunga-20020313-x86-fp-unary
291    Description:
292    
293    Bug fix for:
294    
295    > leunga@weaselbane:~/Yale/tmp/sml-dist{21} bin/sml
296    > Standard ML of New Jersey v110.39.1 [FLINT v1.5], March 08, 2002
297    > - fun f(x,(y,z)) = Real.~ y;
298    > [autoloading]
299    > [autoloading done]
300    >       fchsl   (%eax), 184(%esp)
301    > Error: MLRisc bug: X86MCEmitter.emitInstr
302    >
303    > uncaught exception Error
304    >   raised at: ../MLRISC/control/mlriscErrormsg.sml:16.14-16.19
305    
306    The problem was that the code generator did not generate any fp registers
307    in this case, and the ra didn't know that it needed to run the X86FP phase to
308    translate the pseudo fp instruction.   This only happened with unary fp
309    operators in certain situations.
310    
311    ----------------------------------------------------------------------
312    Name: Matthias Blume
313    Date: 2002/03/13 14:00:00 EST
314    Tag: blume-20020313-overload-etc
315    Description:
316    
317    1. Added _overload as a synonym for overload for backward compatibility.
318       (Control.overloadKW must be true for either version to be accepted.)
319    
320    2. Fixed bug in install script that caused more things to be installed
321       than what was requested in config/targets.
322    
323    3. Made CM aware of the (_)overload construct so that autoloading
324       works.
325    
326    ----------------------------------------------------------------------
327    Name: Matthias Blume
328    Date: 2002/03/12 22:03:00 EST
329    Tag: blume-20020312-url
330    Description:
331    
332    Forgot to update BOOT and srcarchiveurl.
333    
334    ----------------------------------------------------------------------
335    Name: Matthias Blume
336    Date: 2002/03/12 17:30:00 EST
337    Tag: blume-20020312-version110392
338    Description:
339    
340    Yet another version number bump (because of small changes to the
341    binfile format).  Version number is now 110.39.2.  NEW BOOTFILES!
342    
343    Changes:
344    
345      The new pid generation scheme described a few weeks ago was overly
346      complicated.  I implemented a new mechanism that is simpler and
347      provides a bit more "stability":  Once CM has seen a compilation
348      unit, it keeps its identity constant (as long as you do not delete
349      those crucial CM/GUID/* files).  This means that when you change
350      an interface, compile, then go back to the old interface, and
351      compile again, you arrive at the original pid.
352    
353      There now also is a mechanism that instructs CM to use the plain
354      environment hash as a module's pid (effectively making its GUID
355      the empty string).  For this, "noguid" must be specified as an
356      option to the .sml file in question within its .cm file.
357      This is most useful for code that is being generated by tools such
358      as ml-nlffigen (because during development programmers tend to
359      erase the tool's entire output directory tree including CM's cached
360      GUIDs).  "noguid" is somewhat dangerous (since it can be used to locally
361      revert to the old, broken behavior of SML/NJ, but in specific cases
362      where there is no danger of interface confusion, its use is ok
363      (I think).
364    
365      ml-nlffigen by default generates "noguid" annotations.  They can be
366      turned off by specifying -guid in its command line.
367    
368    ----------------------------------------------------------------------
369    Name: Lal George
370    Date: 2002/03/12 12 14:42:36 EST
371    Tag: george-20020312-frequency-computation
372    Description:
373    
374    Integrated jump chaining and static block frequency into the
375    compiler. More details and numbers later.
376    
377    ----------------------------------------------------------------------
378    Name: Lal George
379    Date: 2002/03/11 11 22:38:53 EST
380    Tag: george-20020311-jump-chain-elim
381    Description:
382    
383    Tested the jump chain elimination on all architectures (except the
384    hppa).  This is on by default right now and is profitable for the
385    alpha and x86, however, it may not be profitable for the sparc and ppc
386    when compiling the compiler.
387    
388    The gc test will typically jump to a label at the end of the cluster,
389    where there is another jump to an external cluster containing the actual
390    code to invoke gc. This is to allow factoring of common gc invocation
391    sequences. That is to say, we generate:
392    
393            f:
394               testgc
395               ja   L1      % jump if above to L1
396    
397            L1:
398               jmp L2
399    
400    
401    After jump chain elimination the 'ja L1' instructions is converted to
402    'ja L2'. On the sparc and ppc, many of the 'ja L2' instructions may end
403    up being implemented in their long form (if L2 is far away) using:
404    
405            jbe     L3      % jump if below or equal to L3
406            jmp     L2
407         L3:
408            ...
409    
410    
411    For large compilation units L2  may be far away.
412    
413    
414    ----------------------------------------------------------------------
415    Name: Matthias Blume
416    Date: 2002/03/11 13:30:00 EST
417    Tag: blume-20020311-mltreeeval
418    Description:
419    
420    A functor parameter was missing.
421    
422    ----------------------------------------------------------------------
423    Name: Allen Leung
424    Date: 2002/03/11 10:30:00 EST
425    Tag: leunga-20020311-runtime-string0
426    Description:
427    
428       The representation of the empty string now points to a
429    legal null terminated C string instead of unit.  It is now possible
430    to convert an ML string into C string with InlineT.CharVector.getData.
431    This compiles into one single machine instruction.
432    
433    ----------------------------------------------------------------------
434    Name: Allen Leung
435    Date: 2002/03/10 23:55:00 EST
436    Tag: leunga-20020310-x86-call
437    Description:
438    
439       Added machine generation for CALL instruction (relative displacement mode)
440    
441    ----------------------------------------------------------------------
442    Name: Matthias Blume
443    Date: 2002/03/08 16:05:00
444    Tag: blume-20020308-entrypoints
445    Description:
446    
447    Version number bumped to 110.39.1.  NEW BOOTFILES!
448    
449    Entrypoints: non-zero offset into a code object where execution should begin.
450    
451    - Added the notion of an entrypoint to CodeObj.
452    - Added reading/writing of entrypoint info to Binfile.
453    - Made runtime system bootloader aware of entrypoints.
454    - Use the address of the label of the first function given to mlriscGen
455      as the entrypoint.  This address is currently always 0, but it will
456      not be 0 once we turn on block placement.
457    - Removed the linkage cluster code (which was The Other Way(tm) of dealing
458      with entry points) from mlriscGen.
459    
460    ----------------------------------------------------------------------
461    Name: Allen Leung
462    Date: 2002/03/07 20:45:00 EST
463    Tag: leunga-20020307-x86-cmov
464    Description:
465    
466       Bug fixes for CMOVcc on x86.
467    
468       1. Added machine code generation for CMOVcc
469       2. CMOVcc is now generated in preference over SETcc on PentiumPro or above.
470       3. CMOVcc cannot have an immediate operand as argument.
471    
472    ----------------------------------------------------------------------
473    Name: Matthias Blume
474    Date: 2002/03/07 16:15:00 EST
475    Tag: blume-20020307-controls
476    Description:
477    
478    This is a very large but mostly boring patch which makes (almost)
479    every tuneable compiler knob (i.e., pretty much everything under
480    Control.* plus a few other things) configurable via both the command
481    line and environment variables in the style CM did its configuration
482    until now.
483    
484    Try starting sml with '-h' (or, if you are brave, '-H')
485    
486    To this end, I added a structure Controls : CONTROLS to smlnj-lib.cm which
487    implements the underlying generic mechanism.
488    
489    The interface to some of the existing such facilities has changed somewhat.
490    For example, the MLRiscControl module now provides mkFoo instead of getFoo.
491    (The getFoo interface is still there for backward-compatibility, but its
492    use is deprecated.)
493    
494    The ml-build script passes -Cxxx=yyy command-line arguments through so
495    that one can now twiddle the compiler settings when using this "batch"
496    compiler.
497    
498    TODO items:
499    
500    We should go through and throw out all controls that are no longer
501    connected to anything.  Moreover, we should go through and provide
502    meaningful (and correct!) documentation strings for those controls
503    that still are connected.
504    
505    Currently, multiple calls to Controls.new are accepted (only the first
506    has any effect).  Eventually we should make sure that every control
507    is being made (via Controls.new) exactly once.  Future access can then
508    be done using Controls.acc.
509    
510    Finally, it would probably be a good idea to use the getter-setter
511    interface to controls rather than ref cells.  For the time being, both
512    styles are provided by the Controls module, but getter-setter pairs are
513    better if thread-safety is of any concern because they can be wrapped.
514    
515    *****************************************
516    
517    One bug fix: The function blockPlacement in three of the MLRISC
518    backpatch files used to be hard-wired to one of two possibilities at
519    link time (according to the value of the placementFlag).  But (I
520    think) it should rather sense the flag every time.
521    
522    *****************************************
523    
524    Other assorted changes (by other people who did not supply a HISTORY entry):
525    
526    1. the cross-module inliner now works much better (Monnier)
527    2. representation of weights, frequencies, and probabilities in MLRISC
528       changed in preparation of using those for weighted block placement
529       (Reppy, George)
530    
531    ----------------------------------------------------------------------
532    Name: Lal George
533    Date: 2002/03/07 14:44:24 EST 2002
534    Tag: george-20020307-weighted-block-placement
535    
536    Tested the weighted block placement optimization on all architectures
537    (except the hppa) using AMPL to generate the block and edge frequencies.
538    Changes were required in the machine properties to correctly
539    categorize trap instructions. There is an MLRISC flag
540    "weighted-block-placement" that can be used to enable weighted block
541    placement, but this will be ineffective without block/edge
542    frequencies (coming soon).
543    
544    
545    ----------------------------------------------------------------------
546    Name: Lal George
547    Date: 2002/03/05 17:24:48 EST
548    Tag: george-20020305-linkage-cluster
549    
550    In order to support the block placement optimization, a new cluster
551    is generated as the very first cluster (called the linkage cluster).
552    It contains a single jump to the 'real' entry point for the compilation
553    unit. Block placement has no effect on the linkage cluster itself, but
554    all the other clusters  have full freedom in the manner in which they
555    reorder blocks or functions.
556    
557    On the x86 the typical linkage code that is generated is:
558       ----------------------
559            .align 2
560       L0:
561            addl    $L1-L0, 72(%esp)
562            jmp     L1
563    
564    
565            .align  2
566       L1:
567       ----------------------
568    
569    72(%esp) is the memory location for the stdlink register. This
570    must contain the address of the CPS function being called. In the
571    above example, it contains the address of  L0; before
572    calling L1 (the real entry point for the compilation unit), it
573    must contain the address for L1, and hence
574    
575            addl $L1-L0, 72(%esp)
576    
577    I have tested this on all architectures except the hppa.The increase
578    in code size is of course negligible
579    
580    ----------------------------------------------------------------------
581    Name: Allen Leung
582    Date: 2002/03/03 13:20:00 EST
583    Tag: leunga-20020303-mlrisc-tools
584    
585      Added #[ ... ] expressions to mlrisc tools
586    
587    ----------------------------------------------------------------------
588    Name: Matthias Blume
589    Date: 2002/02/27 12:29:00 EST
590    Tag: blume-20020227-cdebug
591    Description:
592    
593    - made types in structure C and C_Debug to be equal
594    - got rid of code duplication (c-int.sml vs. c-int-debug.sml)
595    - there no longer is a C_Int_Debug (C_Debug is directly derived from C)
596    
597    ----------------------------------------------------------------------
598    Name: Matthias Blume
599    Date: 2002/02/26 12:00:00 EST
600    Tag: blume-20020226-ffi
601    Description:
602    
603    1. Fixed a minor bug in CM's "noweb" tool:
604       If numbering is turned off, then truly don't number (i.e., do not
605       supply the -L option to noweb).  The previous behavior was to supply
606       -L'' -- which caused noweb to use the "default" line numbering scheme.
607       Thanks to Chris Richards for pointing this out (and supplying the fix).
608    
609    2. Once again, I reworked some aspects of the FFI:
610    
611       A. The incomplete/complete type business:
612    
613       - Signatures POINTER_TO_INCOMPLETE_TYPE and accompanying functors are
614         gone!
615       - ML types representing an incomplete type are now *equal* to
616         ML types representing their corresponding complete types (just like
617         in C).  This is still safe because ml-nlffigen will not generate
618         RTTI for incomplete types, nor will it generate functions that
619         require access to such RTTI.   But when ML code generated from both
620         incomplete and complete versions of the C type meet, the ML types
621         are trivially interoperable.
622    
623         NOTE:  These changes restore the full generality of the translation
624         (which was previously lost when I eliminated functorization)!
625    
626       B. Enum types:
627    
628       - Structure C now has a type constructor "enum" that is similar to
629         how the "su" constructor works.  However, "enum" is not a phantom
630         type because each "T enum" has values (and is isomorphic to
631         MLRep.Signed.int).
632       - There are generic access operations for enum objects (using
633         MLRep.Signed.int).
634       - ml-nlffigen will generate a structure E_foo for each "enum foo".
635         * The structure contains the definition of type "mlrep" (the ML-side
636         representation type of the enum).  Normally, mlrep is the same
637         as "MLRep.Signed.int", but if ml-nlffigen was invoked with "-ec",
638         then mlrep will be defined as a datatype -- thus facilitating
639         pattern matching on mlrep values.
640         ("-ec" will be suppressed if there are duplicate values in an
641          enumeration.)
642         * Constructors ("-ec") or values (no "-ec") e_xxx of type mlrep
643         will be generated for each C enum constant xxx.
644         * Conversion functions m2i and i2m convert between mlrep and
645         MLRep.Signed.int.  (Without "-ec", these functions are identities.)
646         * Coversion functions c and ml convert between mlrep and "tag enum".
647         * Access functions (get/set) fetch and store mlrep values.
648       - By default (unless ml-nlffigen was invoked with "-nocollect"), unnamed
649         enumerations are merged into one single enumeration represented by
650         structure E_'.
651    
652    ----------------------------------------------------------------------
653    Name: Allen Leung
654    Date: 2002/02/25 04:45:00 EST
655    Tag: leunga-20020225-cps-spill
656    
657    This is a new implementation of the CPS spill phase.
658    The new phase is in the new file compiler/CodeGen/cpscompile/spill-new.sml
659    In case of problems, replace it with the old file spill.sml
660    
661    The current compiler runs into some serious performance problems when
662    constructing a large record.  This can happen when we try to compile a
663    structure with many items.  Even a very simple structure like the following
664    makes the compiler slow down.
665    
666        structure Foo = struct
667           val x_1 = 0w1 : Word32.int
668           val x_2 = 0w2 : Word32.int
669           val x_3 = 0w3 : Word32.int
670           ...
671           val x_N = 0wN : Word32.int
672        end
673    
674    The following table shows the compile time, from N=1000 to N=4000,
675    with the old compiler:
676    
677    N
678    1000   CPS 100 spill                           0.04u  0.00s  0.00g
679           MLRISC ra                               0.06u  0.00s  0.05g
680              (spills = 0 reloads = 0)
681           TOTAL                                   0.63u  0.07s  0.21g
682    
683    1100   CPS 100 spill                           8.25u  0.32s  0.64g
684           MLRISC ra                               5.68u  0.59s  3.93g
685              (spills = 0 reloads = 0)
686           TOTAL                                   14.71u  0.99s  4.81g
687    
688    1500   CPS 100 spill                           58.55u  2.34s  1.74g
689           MLRISC ra                               5.54u  0.65s  3.91g
690              (spills = 543 reloads = 1082)
691           TOTAL                                   65.40u  3.13s  6.00g
692    
693    2000   CPS 100 spill                           126.69u  4.84s  3.08g
694           MLRISC ra                               0.80u  0.10s  0.55g
695              (spills = 42 reloads = 84)
696           TOTAL                                   129.42u  5.10s  4.13g
697    
698    3000   CPS 100 spill                           675.59u  19.03s  11.64g
699           MLRISC ra                               2.69u  0.27s  1.38g
700              (spills = 62 reloads = 124)
701           TOTAL                                   682.48u  19.61s  13.99g
702    
703    4000   CPS 100 spill                           2362.82u  56.28s  43.60g
704           MLRISC ra                               4.96u  0.27s  2.72g
705              (spills = 85 reloads = 170)
706           TOTAL                                   2375.26u  57.21s  48.00g
707    
708    As you can see the old cps spill module suffers from some serious
709    performance problem.  But since I cannot decipher the old code fully,
710    instead of patching the problems up, I'm reimplementing it
711    with a different algorithm.  The new code is more modular,
712    smaller when compiled, and substantially faster
713    (O(n log n) time and O(n) space).  Timing of the new spill module:
714    
715    4000  CPS 100 spill                           0.02u  0.00s  0.00g
716          MLRISC ra                               0.25u  0.02s  0.15g
717             (spills=1 reloads=3)
718          TOTAL                                   7.74u  0.34s  1.62g
719    
720    Implementation details:
721    
722    As far as I can tell, the purpose of the CPS spill module is to make sure the
723    number of live variables at any program point (the bandwidth)
724    does not exceed a certain limit, which is determined by the
725    size of the spill area.
726    
727    When the bandwidth is too large, we decrease the register pressure by
728    packing live variables into spill records.  How we achieve this is
729    completely different than what we did in the old code.
730    
731    First, there is something about the MLRiscGen code generator
732    that we should be aware of:
733    
734    o MLRiscGen performs code motion!
735    
736       In particular, it will move floating point computations and
737       address computations involving only the heap pointer to
738       their use sites (if there is only a single use).
739       What this means is that if we have a CPS record construction
740       statement
741    
742           RECORD(k,vl,w,e)
743    
744       we should never count the new record address w as live if w
745       has only one use (which is often the case).
746    
747       We should do something similar to floating point, but the transformation
748       there is much more complex, so I won't deal with that.
749    
750    Secondly, there are now two new cps primops at our disposal:
751    
752     1. rawrecord of record_kind option
753        This pure operator allocates some uninitialized storage from the heap.
754        There are two forms:
755    
756         rawrecord NONE [INT n]  allocates a tagless record of length n
757         rawrecord (SOME rk) [INT n] allocates a tagged record of length n
758                                     and initializes the tag.
759    
760     2. rawupdate of cty
761          rawupdate cty (v,i,x)
762          Assigns to x to the ith component of record v.
763          The storelist is not updated.
764    
765    We use these new primops for both spilling and increment record construction.
766    
767     1. Spilling.
768    
769        This is implemented with a linear scan algorithm (but generalized
770        to trees).  The algorithm will create a single spill record at the
771        beginning of the cps function and use rawupdate to spill to it,
772        and SELECT or SELp to reload from it.  So both spills and reloads
773        are fine-grain operations.  In contrast, in the old algorithm
774        "spills" have to be bundled together in records.
775    
776        Ideally, we should sink the spill record construction to where
777        it is needed.  We can even split the spill record into multiple ones
778        at the places where they are needed.  But CPS is not a good
779        representation for global code motion, so I'll keep it simple and
780        am not attempting this.
781    
782     2. Incremental record construction (aka record splitting).
783    
784        Long records with many component values which are simulatenously live
785        (recall that single use record addresses are not considered to
786         be live) are constructed with rawrecord and rawupdate.
787        We allocate space on the heap with rawrecord first, then gradually
788        fill it in with rawupdate.  This is the technique suggested to me
789        by Matthias.
790    
791        Some restrictions on when this is applicable:
792        1. It is not a VECTOR record.  The code generator currently does not handle
793           this case. VECTOR record uses double indirection like arrays.
794        2. All the record component values are defined in the same "basic block"
795           as the record constructor.  This is to prevent speculative
796           record construction.
797    
798    ----------------------------------------------------------------------
799    Name: Allen Leung
800    Date: 2002/02/22 01:02:00 EST
801    Tag: leunga-20020222-mlrisc-tools
802    
803    Minor bug fixes in the parser and rewriter
804    
805    ----------------------------------------------------------------------
806    Name: Allen Leung
807    Date: 2002/02/21 20:20:00 EST
808    Tag: leunga-20020221-peephole
809    
810    Regenerated the peephole files.  Some contained typos in the specification
811    and some didn't compile because of pretty printing bugs in the old version
812    of 'nowhere'.
813    
814    ----------------------------------------------------------------------
815    Name: Allen Leung
816    Date: 2002/02/19 20:20:00 EST
817    Tag: leunga-20020219-mlrisc-tools
818    Description:
819    
820       Minor bug fixes to the mlrisc-tools library:
821    
822       1.  Fixed up parsing colon suffixed keywords
823       2.  Added the ability to shut the error messages up
824       3.  Reimplemented the pretty printer and fixed up/improved
825           the pretty printing of handle and -> types.
826       4.  Fixed up generation of literal symbols in the nowhere tool.
827       5.  Added some SML keywords to to sml.sty
828    
829    ----------------------------------------------------------------------
830    Name: Matthias Blume
831    Date: 2002/02/19 16:20:00 EST
832    Tag: blume-20020219-cmffi
833    Description:
834    
835    A wild mix of changes, some minor, some major:
836    
837    * All C FFI-related libraries are now anchored under $c:
838        $/c.cm      --> $c/c.cm
839        $/c-int.cm  --> $c/internals/c-int.cm
840        $/memory.cm --> $c/memory/memory.cm
841    
842    * "make" tool (in CM) now treats its argument pathname slightly
843      differently:
844        1. If the native expansion is an absolute name, then before invoking
845           the "make" command on it, CM will apply OS.Path.mkRelative
846           (with relativeTo = OS.FileSys.getDir()) to it.
847        2. The argument will be passed through to subsequent phases of CM
848           processing without "going native".  In particular, if the argument
849           was an anchored path, then "make" will not lose track of that anchor.
850    
851    * Compiler backends now "know" their respective C calling conventions
852      instead of having to be told about it by ml-nlffigen.  This relieves
853      ml-nlffigen from one of its burdens.
854    
855    * The X86Backend has been split into X86CCallBackend and X86StdCallBackend.
856    
857    * Export C_DEBUG and C_Debug from $c/c.cm.
858    
859    * C type encoding in ml-nlffi-lib has been improved to model the conceptual
860      subtyping relationship between incomplete pointers and their complete
861      counterparts.  For this, ('t, 'c) ptr has been changed to 'o ptr --
862      with the convention of instantiating 'o with ('t, 'c) obj whenever
863      the pointer target type is complete.  In the incomplete case, 'o
864      will be instantiated with some "'c iobj" -- a type obtained by
865      using one of the functors PointerToIncompleteType or PointerToCompleteType.
866    
867      Operations that work on both incomplete and complete pointer types are
868      typed as taking an 'o ptr while operations that require the target to
869      be known are typed as taking some ('t, 'c) obj ptr.
870    
871      voidptr is now a bit "more concrete", namely "type voidptr = void ptr'"
872      where void is an eqtype without any values.  This makes it possible
873      to work on voidptr values using functions meant to operate on light
874      incomplete pointers.
875    
876    * As a result of the above, signature POINTER_TO_INCOMPLETE_TYPE has
877      been vastly simplified.
878    
879    ----------------------------------------------------------------------
880    Name: Matthias Blume
881    Date: 2002/02/19 10:48:00 EST
882    Tag: blume-20020219-pqfix
883    Description:
884    
885    Applied Chris Okasaki's bug fix for priority queues.
886    
887    ----------------------------------------------------------------------
888    Name: Matthias Blume
889    Date: 2002/02/15 17:05:00
890  Tag: Release_110_39  Tag: Release_110_39
891  Description:  Description:
892    
893    Last-minute retagging is becoming a tradition... :-(
894    
895    This is the working release 110.39.
896    
897    ----------------------------------------------------------------------
898    Name: Matthias Blume
899    Date: 2002/02/15 16:00:00 EST
900    Tag: Release_110_39-orig
901    Description:
902    
903  Working release 110.39.  New bootfiles.  Working release 110.39.  New bootfiles.
904    
905    (Update: There was a small bug in the installer so it wouldn't work
906    with all shells.  So I retagged. -Matthias)
907    
908  ----------------------------------------------------------------------  ----------------------------------------------------------------------
909  Name: Matthias Blume  Name: Matthias Blume
910  Date: 2002/02/15 14:17:00 EST  Date: 2002/02/15 14:17:00 EST

Legend:
Removed from v.1069  
changed lines
  Added in v.1174

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