I will review this one. -Kyle
On 1/22/14 11:53 AM, "Brad Chamberlain" <[email protected]> wrote: > >Still looking for a reviewer to sign up for this one. Reading the commit >message is probably most of the work -- the changes to the code itself >are >pretty straightforward. > >(W.r.t. the modules, don't try to read the diff (because I removed so >much >of the large modules that it's a big diff) -- apply them and then surf >the >modules manually). > >-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.clkt >rk >_______________________________________________ >Chapel-developers mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/chapel-developers ------------------------------------------------------------------------------ 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
