BTW, if you decide to apply the patch and it doesn't apply cleanly due to the way I svn cp'd and then modified the existing modules, try doing a cp -r of your modules/ directory to modules-minimal/ and then applying it. Of course in doing this, you'll get more than the 6 modules I list below, but imagine the others aren't there.
-Brad On Tue, 21 Jan 2014, Brad Chamberlain wrote: > > Hi all -- > > This is a patch implementing the "minimal modules" compilation mode that I > proposed a week or so ago which I'd like to request a review for. Proposed > log message below. > > -Brad > > ----- > > Add support for a "minimal modules" compilation mode > > This commit adds support for a developer flag, --minimal-modules, in > which Chapel programs are compiled with a minimal amount of internal > and standard module support. This means that the language will be > virtually crippled (since so much of Chapel is defined within > modules), but it permits a developer to work on compiler > transformations in the core of the language without having to worry > about getting all of the internal/standard modules to compile properly > before evaluating their result. > > As an anecdote, I've been wondering recently about changes to the way > we (1) represent ref intents and (2) implement assignments within the > compiler, but in changing either concept, it can take so long to work > through all of the issues that arise in the internal modules that it's > hard to determine whether I'm making progress or not. With the > --minimal-modules flag, I was able to make a simple change to the > compiler to try issue 1 above and see its impact on the generated code > without wrestling through all of the issues that would have arisen > using the full set of internal modules. > > Of course, in some sense, this is just postponing the inevitable, but > the hypothesis is that it enables you to see that you're making a > correct/reasonable change earlier than you might otherwise be able to > determine if you were compiling the normal modules in full. Over > time, it may also be a means for us to determine which parts of the > internal/standard modules are particularly brittle or antiquated > w.r.t. the current language definition/compiler architecture, and > make them less so. > > The general strategy here was to make a clone of modules/internal > (called modules-minimal/internal) and then to rip out all but the most > essential components. When compiling with --minimal-modules, we use > that clone rather than the normal modules. The intent is that the > minimal-modules directory will not be bundled in the release since > it's a developer feature and just adds clutter to the top-level > directory. > > One design decision was to avoid changing the interface between the > runtime and compiler-generated code/modules in order to avoid having > to maintain different builds of the compiler when using > --minimal-modules vs. not. > > What remains in modules-minimal are six modules that correspond to > their full-blown counterparts, and make the following definitions: > > ChapelBase.chpl: > - proc =() : in its most generic form > - _ref : the standard ref class/type mechanism > - chpl__initCopy() : in its most generic form > - chpl__autoCopy() : in its most generic form > - chpl__autoDestroy() : in its most generic form > > PrintModuleInitOrder.chpl: expected by the compiler, but empty here > > ChapelStandard.chpl: expected by the compiler, now use's the next 3 > modules: > > ChapelTaskTable.chpl: > - chpldev_taskTable_*() : called from the runtime, all no-ops now > > MemTracking.chpl: > - chpl_memTracking_returnConfigVals() : called from runtime, now a no-op > > ChapelUtil.chpl: > - chpl_main_argument : the argument type passed to chpl_main() > - chpl_rt_preUserCodeHook : a call into the runtime prior to user code > - chpl_rt_postUserCodeHook : a call into the runtime after user code > > The effect of taking everything else out is that none of Chapel's more > exotic types which are defined using modules are available (i.e., no > ranges, domains, arrays, tuples, sync/single, atomics). As a result, > parallelism is similarly unlikely to work (since it relies on > synchronization types internally). Similarly, basic/core operations > like +, -, *, /, ... casts, etc. are not defined due to their reliance > on module code. > > Naturally, a developer can incrementally add such functionality back > to their copy of modules-minimal, or to a specific test, but it won't > be included by default (for fear of there not being a clear place to > draw the line). > > > Apart from the modules themselves, here are the changes involved, by > file: > > runtime/src/chplmemtrack.c > -------------------------- > as mentioned above, the routine in MemTracking.chpl is now a no-op, so > I changed the initializations of some variables here so that they'd > have legal/appropriate values whether or not this routine did anything. > > > compiler/util/files.cpp > ----------------------- > made the module search path switch between 'modules-minimal' and > 'modules' depending on whether or not --minimal-modules is thrown. I > made all of the normal search paths use this same base directory, even > though most of the subdirectories under modules-minimal don't exist. > My rationale was so that if a developer wanted to replicate some of > the other module files in their usual subdirectories it would be easy > to do so. Ultimately, we may want the ability to specify a root > module directory via a compiler flag, but I didn't go that far here. > > > compiler/include/driver.h > compiler/main/driver.cpp > ------------------------- > added the new --minimal-modules flag and an fMinimalModules global to > store its state > > > compiler/main/config.cpp > ------------------------ > when compiling with --minimal-modules, stubbed out the checks for some > standard configs because they're not defined in this mode > > > compiler/passes/filesToAST.cpp > ------------------------------ > when compiling with --minimal-modules, stubbed out the error thrown if > we don't find standard module-defined types like _array, _tuple, etc. > because they're not defined in this mode > > > compiler/AST/astutil.cpp > ------------------------ > protect 'object' from being dead-code eliminated. The compiler relies > on its presence, but usually it gets preserved automatically through > the creation of classes in the internal modules. Now that we don't > create any classes there, we need to special-case it. > > > compiler/passes/buildDefaultFunctions.cpp > ----------------------------------------- > when compiling with --minimal-modules, don't deal with endcounts in > main() (because it relies on synchronization types that aren't > supported in this mode); and don't create default I/O routines for > records (because QIO isn't supported). The former is a necessity; the > latter is probably just a case of avoiding pointless work (i.e., > I'm guessing it wouldn't hurt to re-enable it, but didn't bother > trying). > > > compiler/AST/astutil.cpp > compiler/passes/addInitGuards.cpp > compiler/resolution/functionResolution.cpp > --------------------------------- > when running with --minimal-modules, I stubbed out the code relating > to printing the module initialization order for simplicity and fear > that it relied on QIO. Turns out that it doesn't relate to QIO (I > think) and probably could be re-enabled, but the simplicity argument > still sticks. If the routine doesn't exist (and it doesn't when > compiling with --minimal-modules), gPrintModuleInitFn will never be > assigned, so these files now stub out the related actions when it's > NULL. > > > test/compflags/bradc/minimalModules > test/compflags/bradc/minimalModules/minModDeclPrint.good > test/compflags/bradc/minimalModules/minModFnRefArg.chpl > test/compflags/bradc/minimalModules/COMPOPTS > test/compflags/bradc/minimalModules/minModFnRefArg.good > test/compflags/bradc/minimalModules/minModDeclPrint.chpl > --------------------------------------------------------- > added a few tests that I used while developing this, just to lock the > behavior in, should the key interfaces change > ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
