This seems like a good idea to me. I've encountered problems to Brad's
when working on function resolution: I would change something and then try
and run it on a small example to see how a particular case is handled only
to have the compiler throw an error on something deep inside the standard
library. Being able to work with a much smaller AST would let developers
focus in on the changes they are interested in before testing their
modifications on the whole Chapel code base.
An alternative way of achieving the same result might be to increase the
granularity of the modules and try and include modules only when they are
absolutely needed. Right now data types and functions are pulled into an
application even if these features aren't needed. I imagine that this
would take a lot more work though, so I'm not proposing that we do this
now; I just wanted to bring it up for discussion.
- Chris
On Wed, Jan 22, 2014 at 2:56 PM, Kyle Brady <[email protected]> wrote:
> 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
>
------------------------------------------------------------------------------
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
