I'd like to request moving the minimal modules dir to under modules/, e.g. trunk/modules-minimal --> trunk/modules/minimal. The current setup messes with tab extension in my most-commonly-used tab extension scenario.
An alternative would be to rename trunk/modules-minimal to trunk/minimal-modules. Which has the side benefit of improved readability. Vass -------- Original Message -------- Subject: [Chapel-commits] SF.net SVN: chapel:[22575] trunk Date: Wed, 22 Jan 2014 21:55:58 +0000 From: <[email protected]> Reply-To: <[email protected]> To: <[email protected]> Revision: 22575 http://sourceforge.net/p/chapel/code/22575 Author: bradcray Date: 2014-01-22 21:55:57 +0000 (Wed, 22 Jan 2014) Log Message: ----------- Add support for a "minimal modules" compilation mode [reviewed by Kyle and partially by Greg] 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 ** One important note here is that, in order to avoid bringing in SysCTypes.chpl along with everything it requires, I hard-coded some arguments that are actually size_t to be uint(64) which is a non-portable solution, but probably sufficient for most developers to use (the audience for this patch) and unlikely to cause any significant problems given that the function is a no-op anyway. If this does give anyone hassles, let me know and we can consider other options. 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 Modified Paths: -------------- trunk/compiler/AST/astutil.cpp trunk/compiler/include/driver.h trunk/compiler/main/config.cpp trunk/compiler/main/driver.cpp trunk/compiler/passes/addInitGuards.cpp trunk/compiler/passes/buildDefaultFunctions.cpp trunk/compiler/passes/filesToAST.cpp trunk/compiler/resolution/functionResolution.cpp trunk/compiler/util/files.cpp trunk/runtime/src/chplmemtrack.c Added Paths: ----------- trunk/modules-minimal/ trunk/modules-minimal/internal/ trunk/modules-minimal/internal/ChapelBase.chpl trunk/modules-minimal/internal/ChapelStandard.chpl trunk/modules-minimal/internal/ChapelTaskTable.chpl trunk/modules-minimal/internal/ChapelUtil.chpl trunk/modules-minimal/internal/MemTracking.chpl trunk/modules-minimal/internal/PrintModuleInitOrder.chpl trunk/test/compflags/bradc/minimalModules/ trunk/test/compflags/bradc/minimalModules/COMPOPTS trunk/test/compflags/bradc/minimalModules/minModDeclPrint.chpl trunk/test/compflags/bradc/minimalModules/minModDeclPrint.good trunk/test/compflags/bradc/minimalModules/minModFnRefArg.chpl trunk/test/compflags/bradc/minimalModules/minModFnRefArg.good This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ------------------------------------------------------------------------------ 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-commits mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-commits ------------------------------------------------------------------------------ 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
