adding miniMD to release and DOE

git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@21922 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
adding nolocals

git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@21923 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Pass atomics by ref by default

[reviewed by vass]

This commit changes the default intent for atomic types to 'ref'.  In
the original commits to atomics, no effort was put into defining or
implementing argument passing semantics, and as a result, they've been
passed around in an ad hoc manner.

The rationale for passing them by reference is that the identity of
atomic types (like other synchronization types) is important rather
than just their value, so that multiple tasks are synchronizing on the
same memory location.  Thus, going by our traditional "blank should
support the common/typical case" strategy, making them 'ref' is the
logical conclusion.

As we move toward supporting task intents (and 'blank' task intents by
default), it also makes sense to make atomics 'ref' because they are
only useful when multiple tasks can access and modify them; so by
making blank mean anything else, the implication would be that most
atomics that cross task creation boundaries would need to be labeled
with a 'ref' clause to override that default.  For this reason, we've
been considering this commit to be a necessary precursor to the
forthcoming task intents commit.

The core of this commit is fairly simple modifications to
resolveIntents.cpp.  These changes were sufficient to get --local
testing working.  The main thing to note in this file is that I chose
to make 'const' mean 'const in' for atomics (rather than 'const ref'),
on the argument that they tend to be scalar types in the common
(intrinsics) support for atomics, and so passing them by 'const ref'
seems like overkill.  A counterargument might be that sync variables
are passed by 'const ref', so for consistency, perhaps both
synchronization-oriented types should have the same behavior under
'const'.  My rationale for choosing 'const in' prioritized efficiency
over symmetry -- I'd rather pass the large record that sync variables
tend to use by reference and the small value that atomics tend to be
by value.  But we may want to revisit this in the future (and at
present, we've said that the compiler can choose what 'const' means,
so a user shouldn't be relying on one interpretation or the other
anyway).

Supporting --no-local testing was more complicated and required
modifications to functionResolution.cpp to mark formal atomic types as
'ref' types, similar to what we do in other by-ref cases.  This in
itself was primarily complicated by the fact that we have to analyze
blank intents for atomics before the intents have been resolved.  To
this end (and a few other related challenges), Vass and I have been
discussing folding resolveIntents into functionResolution so that once
we know an argument's type there wouldn't need to be any further
special handling of const or blank intents.  I think this is a smart
move, and while it goes against the original goal of making
resolveIntents its own pass to keep functionResolution from getting
any bigger, it actually may make function resolution smaller by
removing a lot of the special case code that repeats this similar
analysis (and possibly misses some cases).  So this is a housecleaning
TODO that I hope to spend more time on in the future.

One thing about this commit that was dissatisfying was that there were
a handful of cases that pass atomics by blank intent (primarily in
internal module code) which broke if we didn't dance around them in
functionResolution.cpp: constructors, generic assignment-to-atomic
overloads, and tuples that capture atomics.  More discouraging is the
fact that I can't adequately explain why the special cases are needed
(I didn't have time to investigate further this week, and wanted to
get this in to support task intents for the release).  In the comments
to my helper function that determines whether an atomic argument type
should be changed to a ref type, I noted the primary tests that fail
without these special cases.  For the most part, these special cases
only affect the Chapel developer (who has to deal with the added
complexity in functionResolution.cpp) rather than the user, although
the one case that could surprise the user is that a constructor that
takes an atomic argument by blank intent will not get a reference to
that atomic in the --no-local case.  I added a bug future to track
this case and hope to investigate further in the future.

To support the special cases of building tuples of atomics, I had to
add a new flag to identify the functions used to build tuples and then
used them to flag these functions in
modules/internal/ChapelTuple.chpl.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@21924 3a8e244f-b0f2-452b-bcba-4c88e055c3ca