SCM Repository
View of /sml/trunk/src/compiler/TODO
Parent Directory
|
Revision Log
Revision 46 -
(download)
(annotate)
Sun Mar 22 20:11:09 1998 UTC (22 years, 11 months ago) by monnier
File size: 4120 byte(s)
Sun Mar 22 20:11:09 1998 UTC (22 years, 11 months ago) by monnier
File size: 4120 byte(s)
This commit was generated by cvs2svn to compensate for changes in r45, which included commits to RCS files with non-trunk default branches.
TODO: a. lcontract should do the following: o reduce the code to normal form in one pass (no surprising redices) o should contract type applications (i.e., polymorphic functions that only applied once) o how lcontract interacts with specialize ? how many rounds of lcontract should be applied, before or after specialize ? we should borrow the "accounting" heuristics in cpsopt. b. ppflint --- probably should be less verbose on some canonical case, e.g., FIX((_,f,_,_), RET[VAR f]) also if the body is very small, we don't have make a new line. see pplexp.sml printing primops can be made less verbose, instead PRIMOP blah blah just simply "x + 1" would do. c. flintutil.sml: how to represent the wrap, unwrap and etag primops ? should they be monomorphic or polymorphic d. flintnm.sml: recursions vs. true recursions. I hope that something can be done on splitting pseudo recursions into separate FIX decs. e. lcontract + specialize: how to adjust the lty and tyc when we have to inline or specialize functions from one depth to another is a major headache of using the de-Bruijn-index-based representations. I have tried different ways in lcontract and specialize, but it is pretty adhoc, it will be nice if we can show a more general way of how this should be done. f. Type specialization will lead to many new redices for the lcontract; I currently will run one round of lcontract after specialize (see the end of lcontract.sml). Is this an overkill ? g. For a simple int list constant such as "[3]", the compiler generates the following after the representation analysis: this is way too much work; several issues have to be dealt with: first the "ltc_unit" and the "unit" constant; second is how to avoid trivial wrappers such as those generated from wrapping a RECORD; third is how to avoid useless LET redices from the coerce procedure. v3 : (FK_FCT) = FN([v2 : S{}], v6 = RECORD [] [v8] = [v12] = v13 = WRAP(TT<>, v6) RETURN [v13] RETURN [v12] v5 = CON(nil, [I], v8) v4 = RECORD [(I)3,v5] [v9] = [v10] = v11 = WRAP(TT<I,LST[I]>, v4) RETURN [v11] RETURN [v10] v1 = CON(::, [I], v9) v7 = STRUCT [v1] RETURN [v7]) h. Files that needs further clean-up --- ltykernel.sml and wrappingNEW.sml --------------------------------------------------------------------------- TODO: a. push lcontract into FLINT (* easy *) b. push specialize into FLINT (* some work *) c. push reps into FLINT (* rework *) d. push narrow into FLINT (* easy *) e. push convert into FLINT (* register pressure ? *) f. turn on the FLINT typechecker (* CHRIS & VALERY *) g. turn on the FLINT pretty printer (* CHRIS & VALERY *) --------------------------------------------------------------------------- OTHER: B eliminate pointers to the middle of closures ... C clean up the copyright/etc in all the source files C parametrize the cross-module linkage conventions 1. add code splitting 2. get rid of LT_PST through advanced linkage interface 3. new array splitting (code splitting, phase 1) 4. all require runtime support in LoadBinFile in new-boot.c C. delay inlining of array primops to the backend --------------------------------------------------------------------------- DONE: X merge EXNC and EXNF into ETAG; (fixing exn flag typing) X treat non-value carrying datatypes as unit-carrying ... X merge EXNCONS and EXNFUN ? X propagating datatypes into the middle-end X clean up the primitives such as PACK and WRAP ... X move the execution semantics from CM back into compile or evalloop X change lambda from Lambda.lexp to FLINT.prog 1. eliminate the PLambda to Lambda normalize module 2. plambda is now part of the "trans-mcomp" phase X push FLINT into inl_info (?) and cleanup the CM interface
root@smlnj-gforge.cs.uchicago.edu | ViewVC Help |
Powered by ViewVC 1.0.0 |