Changing a couple of vars to consts after reviewing the barrier code.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19852 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Fixing a few spelling errors.

I did not do a complete review, just fixing the existing spelling
errors.

Who the heck wrote this thing anyways?!!?!



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19853 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Fix performance bug with ref counting using atomics.

For the list lock in the distribution and domain classes, if the
acquire happened on a different locale than the one that the class was
allocated on, each test of the lock resulted in an on to the remote
locale.  Highly undesirable if there is contention.

Since we know that we will need to do at least one remote fork for the
lock, we might as well wrap the remove_* and add_* code in an on
clause.  The lock function is only called within the remove_* and
add_* so rather than adding a redundant on, I just put a comment in
there that warns that if the lock is to be acquired from a remote
locale, we should wrap it in an on clause.

Also, updated a test that expected an error that included line numbers
from ChapelDistribution.chpl.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19854 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Added feature request futures on allowing assignment to 'this' and on propagating constness from a variable of a class or record type to its fields (and further).

These are a follow-up to a discussion between Brad and Vass, but the
motivation and some ideas have been discussed elsewhere, too.


Example from constnessOfThisInMethods.future:

    record R { var x: int; }
    proc R.mod()   { x = 5; }
    proc R.nomod() { writeln(x); }

    var r1: R;
    r1.nomod();
    r1.mod();

    const r2: R;
    r2.nomod();
    r2.mod();  // compiler must report error here; the previous calls are fine
    r2 = r1;   // correctly disallowed today

Rationale: in my mind, 'const r2' means the program is disallowed
to modify r2's value. The latter means exactly modifications of r2's fields.


From propagateConstnessOfVariableToFields.future:

Today the const-ness of a field is the same for all instances of the class.
In some cases it is limiting: instead, we'd like a field to be constant
if the instance is referenced by a 'const' variable, otherwise we'd like
the field to be variable.

Const-ness of a record field declared as 'var' already follows the constness
of the variable that stores the record.
However, even within a record, it may be desirable to propagate its
constness into its fields. E.g. if the record has the field myC that
is of a class type C, we may want the constness of C's fields to
match the constness of the myC field that references the C instance.


Both .futures also sketch some ways to provide these features.


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19855 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Remove the uGNI comm layer include and src subdirs.

We don't need these permanently in the repository, as it turns out.


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19856 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Ignore any runtime ugni comm layer subdirectory.

Set the svn:ignore property so that any temporary ugni subdirectory of
runtime/include/comm or runtime/src/comm will be ignored by svn.


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19857 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Change dev-tasks-1 to muxed and dev-threads-1 to soft-threads.

This commit changes the names of a couple of internal development
tasking and threading layer implementations from dev-tasks-1 and
dev-threads-1 to muxed and soft-threads, respectively.  These are
proprietary implementations for which we don't expect to release source
code, but it is convenient for us to be able to refer to them by their
real names rather than the pseudonyms we've been using prior to this.

The specific file changes are as follows.

util/chplenv/tasks
util/chplenv/threads
util/chplenv/check-tasks-threads-compatibility
  Change dev-tasks-1 to muxed and dev-threads-1 to soft-threads.

runtime/include/tasks
runtime/src/tasks
  Set the svn:ignore property to ignore a muxed subdirectory.

runtime/include/threads
runtime/src/threads
  Set the svn:ignore property to ignore a soft-threads subdirectory.

runtime/etc
  Set the svn:ignore property to ignore a Makefile.soft-threads file.

modules/internal
  Set the svn:ignore property to ignore muxed and soft-threads
  subdirectories.


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19858 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Removing unnecessary .compopts file

The compopts file passed some flags to the back end compiler that are
no longer needed now that we support atomics directly in the language.




git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19859 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Fixing class ID regression

[reviewed by Sung]

When changing default 'int' to 64-bits, a subtle regression creeped
in, in which a 64-bit temp was used to store the dynamic class ID of
a remote class when remote dynamic dispatch was executed.  Under
certain conditions, this caused problems.  After discussing options
with Sung, we decided to change the enumeration used to store dynamic
IDs in classes into a fixed-width integer in order to remove uncertainty
in the C code about how wide the type is.  This commit changes it to
a 32-bit int.

We talked about having the compiler automatically use a class ID that
was the minimum required width since this ID takes up space in every
object, and in most cases, an 8- or 16-bit int would be plenty.  However,
in the end we had concerns about what the alignment of this value would
be and whether that might cause communication problems for one-sided
communication.  This may have been overly conservative, but given the
close timing to the release date, it seemed prudent for the time being.

The main downside to this change is that we lose some of the symbolic
elegance in debugging of not having the enum value.  If this becomes
an issue, we discussed introducing a routine that would map class IDs
back to strings.  Please feel free to request this if/when it would be
of use to you.





git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19860 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Adding prediff to reduce test maintenance

git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19861 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Removing no-longer-useful comments.

Change requested by Vass.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19862 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Retiring future which Michael fixed



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19865 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Updating REGRESSIONS based on past few days' work

I stupidly svn reverted some changes one night in a bad moment, so
this is missing a day or two of entries that I haven't worked up the
stomach to re-enter.  Since I owe a review of this file anyway for the
release, I'm dragging my feet on that for now.

In better news, though...

+ types/range regressions due to int->64 change resolved

+ linux32 int->64 regressions fixed

+ qthreads working much better with new config options and syncvar
  implementation

- new nondeterministic failure in the CCE compiler when compiling
  spec/Generics/query.chpl

* more valgrind issues due to unhandled syscall (waiting on valgrind upgrade)

* normal nondeterminisms



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19866 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Removing volatile types from the implementation and documentation

We recently decided to retire volatile types but never got around to
doing it.  The rationale was that atomic types are what we really want
(and that, as a fallback, we should support bettern extern type
declarations that are preserved to codegen at which point a user could
create an extern type to get at C's volatile types if they wanted).

Now that we've got atomics, I finally got around to pulling out this
code (removing dead code is fun!)



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19867 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Wait for private broadcast completion.

Currently the GASNet comm layer does non-blocking private broadcasts.
It fires an Active Message request to each remote locale to update the
appropriate chpl_private_broadcast_table[] entry, but does not wait for
an acknowledgement that that update has occurred before it goes on.  We
became concerned that there might be a scenario in which this would
allow a locale to reference a chpl_private_broadcast_table[] entry
before it was initialized, so this commit makes the private broadcast
logic wait for remote acknowledgement before continuing.

We add a vector of done flags to the broadcast function, one flag for
each locale.  Each transmission in the broadcast includes the address of
the appropriate flag in the descriptor that is sent to the AM handler.
The AM handler does a reply to set the flag after it has updated the
remote chpl_private_broadcast_table[] entry.  In order to minimize the
total time spent waiting for acknowledgements, the sender does all the
transmits and only then waits on all the flags.

This was reviewed by Sung.


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19868 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Update comm diagnostics after the atomics ref count change.

For Kernels 2 & 3, the number of remote gets decreased slightly.

For Kernels 2, 3, & 4, the number of remote puts increased less slightly.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19869 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Factor some more functions in functionResolution.cpp.

Factored resolve_type_constructor() from addCandidate().
Factored gatherCandidates out of resolveCall().
Factored resolveCall() into several functions, to handle separately cases where
  the call is a primitive.
Factored instantiate_default_consructor() from resolveFns().
Added comments.


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19871 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Correct bad merge of moved volatile removal commit.

git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19872 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Adjusted the distribution robustness suite README to mention the BlockDist default since r19743.


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@19873 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Switched the release version of HPL to using DimensionalDist2D with BlockCyclicDim and ReplicatedDim; augmented DimensionalDist2D with DimensionalArr.dsiReindex(); modified printLocalesTasks() in HPCCProblemSize.chpl to print locale grid dimensions, optionally.

This conversion of HPL favored elegance over performance.
Cf. test/studies/hpcc/HPL/vass/hpl.chpl - is performance-oriented.


To improve the performance, could do the following (of which, most
non-compiler mods are done in test/studies/hpcc/HPL/vass/hpl.chpl):

* Allocate replA/replB (and their domains) just once at the beginning,
rather than for each call to schurComplement() - to reduce the overhead
of allocation/deallocation and privatization.

* Place Ab, replA, ReplB in the global scope and do not pass them around
as arguments. Or fix the compiler bug whereas in the generated code
the following code (or a variant thereof) results in a remote reference
for A(i) (to read A's pid) even when 'A' is privatized and A(i) is local:

    proc example(A) {
      on (a remote locale) do A(i);
    }

* Make the computation of Rest.dim(1)(row..#blkSize) and ...dim(2)...
in schurComplement() local, by computing them outside the 'local'
clause - or by fixing the compiler?

* Enable 'local' in schurComplement() after doing the above.

* Hoisting the above slicing of Rest from inner loopnest(s).

* Try various permutations of the 3 for loops in schurComplement()
to see which is the fastest.

* replicateD1()/replicateD2() always replicate the whole row/column.
Once our slicing becomes cheaper, we can consider
replicating only the needed data during the last several
iterations in LUFactorize. For a large problem size, though,
we expect this to offer only a small performance improvement.

  The version in test/studies/hpcc/HPL/vass creates the four dimension
specifiers {dim1, dim2} * {block-cyclic, replicated} just once then
uses them when creating various Dimensional-mapped arrays. The version
being committed creates those specifiers right in the 'dmapped' clauses.
The advantage of the former is ensuring that they [the specifiers] are
consistent among themselves and among their uses.
(I don't think performance is a consideration here.)


Other notes:

* Switched the domain map for 'Ab', 'MatVectSpace' et al.
from the multi-dimensional BlockCyclic to DimensionalDist2D
with BlockCyclicDim in each dimension. The motivations were
to try out DimensionalDist2D and ensuring consistency in
index-to-locale mapping with replA/replB?

* Inlined dgemmNativeInds(), primarily to avoid figuring out
how to make it work with the replicated arrays. Part of it
is that I felt it was simpler to have the smaller dimension
of the replicated arrays to be 1..blkSize, rather than
(some starting point)..#blkSize. Or maybe because this makes
for fewer array slice expressions, which are currently expensive.

* Only schurComplement() takes advantage of replication.
The overhead of replication currently makes it unprofitable
for panelSolve() and updateBlockRow().

* Hoisted into separate functions the creation of replA, replB and the
replication of Ab into replA/replB - so that the top-level code is tidier
(e.g. main(), LUFactorize()). But see performance discussion above.

* Explicitly computed the dimensions of the locale grid to compute on
(gridRows, gridCols). That's because each dimension specifier constructor
is currently set up so that it needs the extent of its locale grid dimension.
Also the DimensionalDist2D constructor needs the locale grid array,
so Locales is reshaped into targetLocales explicitly, too.

  Again, hoisted computations into helper functions to keep top-level
code tidier.

  When computing gridRows and gridCols, the grid is either rectangular
or with second dimension larger than the first dimension.
This is because others tend to use grids N * (2*N).

* Added a condition to invoke schurComplement() only when 'br' aka 'Rest'
is non-empty. This is (a) to avoid useless replication and (b) because
replication currently assumes that the row/column being replicated
are blkSize-high/wide. This assumption could be fixed, but it seems
easier just to provide the conditional.

* Fixed a couple of comments.


Implemented aliasing for DimensionalDist2D-mapped arrays.

  This is so that I could write 'const replA => replicateD2(Ab...)'
in HPL. That's because 'const replA = replicateD2(Ab...)' would be
less efficient (it would entail copying, not aliasing)
and incorrect to begin with (it would copy only one replicand
of the r.h.s., leaving the other replicands of the l.h.s.
unassigned). We could avoid aliasing but at the expense
of some loss of code elegance.

  Aliasing is implemented by proc DimensionalArr.dsiReindex().
It currently works only for aliasing, and will generate
a run-time error upon a general reindexing of
a DimensionalDist2D-mapped array.


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