Only run multilocale suite for qthreads+flat+gasnet testing on chap13.

Discussed change with sungeun + gbtitus.

git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22815 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Change the wording for when compiler performance keys are matched

[not reviewed, trivial] 

Brad noticed that compiler performance runs had ~8k successes instead of the
usual ~4k. The reason was that compiler performance testing would print out
"success matching ..." on successful matches which is the keyword that
start_test looks for when counting the number of successes. To avoid this, this
patch just changes the wording from success matching to success finding. This
only affects compiler performance runs and not regular performance runs. 


git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22816 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Skip this test for numa -- it's more like multilocale than --local



git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22817 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Revert the test changes in r22744. [reviewed by mferguson]

Back out the changes in tests
  remote-record-write-1
  remote-tuple-write-1
  remote-tuple-write-small-1
due to 22744, and instead update the .good files.

r22744 was intended to address performance regressions resulting from the
adoption of the new signature for the assignment operator (r22674).  Those
performance regressions were due to the fact that the "old-style" assignment
went ahead and performed a field-by-field copy (of records and (by subsumption)
tuples) by default -- as required by the specification.  The result was then
copied to the destination by the automatically-added MOVE primitive -- a
workaround used to implement assignment before the "ref" intent was available.

In the old implementation, the field-by-field assignment was performed locally
and the remote write was done in bulk, so the field-by-field copy did not
create additional network traffic.  In the new implementation, the
field-by-field update spans locales, so communication counts are higher.

The quick-fix solution was to write custom implementations of the assignment
operators for the record and tuples used in the affected tests.  But this is
just a manual implementation of an optimization that should be performed
automatically.  Accepting the new behavior should work as a goad to implement
this optimization.

For completeness, the optimization is described here:
  When copying a record, the element-by-element copy can be replaced by a bulk
  copy, provided that such a replacement does not change the semantics of the
  operation.
  The compiler knows the semantics of the assignment operators it generates
  automatically, but does not know the semantics of user-supplied assignment
  operators.  The compiler-generated assignment operators implement the
  required field-by-field copy, which when applied recursively devolves to a
  bitwise (bulk) copy.  Therefore, a compiler-generated assignment can be
  replaced by a bulk copy, but only if none of the field-wise assignments uses
  a user-defined assignment operator (recursively).

  The algorithm suggested by the above discussion is:
    For each call to an assignment operator:
      Get the function being called
      If the function is user-defined:
        continue
      If each of the field-wise assignments is compiler-defined (recursively):
        replace the assignment call with a 'move' primitive



git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22818 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Only beautify generated code if savec is enabled 

[reviewed by sung a while ago]

It turns out that beautify takes a pretty significant amount of time. Around
95% of the total codegen time so around half a second. By turning this off it
will make compiles that do not use savec faster. This should result in  a ~30
minute speedup for nightly testing. 


git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22819 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Kyle noticed that the release version of chameneos redux was generating
different output during performance runs when compared to the studies/shootout
directory.  Since these tests are here both to demonstrate Chapel performance
and to demonstrate our implementation of these benchmarks, I decided to change
it to match that of the studies/shootout directory, and updated the README to
inform why that file was different.



git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22820 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Make "is tuple type" compiler primitive [suggested by Brad, very straight-forward]

The module method isTupleType(type t) previously took the type, created a var
using it, and then checked if that var was a tuple.  This is unnecessary and
would have led to some infinite recursion in my initialization work.  To combat
this, I created a compiler check similar to the "is star tuple type" primitive
which utilized FLAG_TUPLE's existence.

Tested over std.


git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22821 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Adding executable property to this script

(I missed it in my original commit and have been working from a local
mod ever since).



git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22822 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Make the polling architecture more symmetric and simple.

[Reviewed by David.]

This rearranges polling in the gasnet comm layer so that it happens the
same way on all locales, with respect to tasking.  It used to be the
case that on locale 0 we polled in a task or thread acquired from the
tasking layer, while on other locales we polled in the main process
associated with the locale.  To take into account the load imposed by
communications polling, tasking layers had to have implicit knowledge of
this difference between locales.  Now gasnet does polling in a task or
thread acquired from the tasking layer on all locales.  The tasking
layer logic can therefore depend on explicit information, such as the
value returned by chpl_comm_numPollingTasks(), in deciding how to deal
with any polling load.

The change to call the tasking layer to start a polling task on all
locales is quite simple.  However, there is some added complication in
chpl_comm_pre_task_exit(), where we do the barrier across locales at the
end of the user code.  On the non-0 locales we cannot just call a
barrier function.  The gasnet barrier functions put callers to work
polling, and the callers of chpl_comm_pre_task_exit() on non-0 locales
are the locale processes.  They arrive in chpl_comm_pre_task_exit()
quite early, basically just as locale 0 is invoking the user code.  If
they did simple barrier calls they would thus compete for polling work
with the polling tasks or threads we just set up.  Therefore we go to a
little extra work on the non-0 locales, and set up a slow spin wait so
that we satisfy the barrier in a timely way while not interfering with
the polling.

While here, I also added an internal barrier function implemented in
terms of gasnet's barrier identifiers.  Barriers with identifiers will
allow catching certain barrier mismatches, which seems like a nice thing
to be able to do (and helped find a problem in an early version of this
mod).  I'll adapt more code to use these in the future; for now, so as
not to confuse the purpose of this commit, I'm just using this kind of
barrier in one instance.


git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22823 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Remove _ensure_reference_type()

[Reviewed by David and discussed by the peanuts in chat]

This was originally added to create reference type explicitly.  Now
the compiler creates any as required, and so _ensure_reference_type()
and any calls to it are no longer needed.




git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22824 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Add performance test verification

[reviewed by lydia & tom]

This patch adds the ability to verify that performance tests are working as
expected.

It adds two special 'perfkeys': verify and reject. When the regex in a verify
line matches, it is counted as being a success. A match in a reject line is
counted as a failure. If multiple verify or reject lines are in a perf keys
file the results are logically and'ed together.

verify: <regex>
verify:lineno: <regex>
verify:-lineno: <regex>

reject: <regex>
reject:lineno: <regex>
reject:-lineno: <regex>

lineno specifies what line of the output the check should match against.  If
lineno is negative the lines are counted from the end of the file to the
beginning. If no line number is given the match can be on any line.

Example line numbering of a file:
1:-3: 1 2 3 4 5
2:-2: 6 7 8 9 0
3:-1: FAILURE

When the test fails, no data is recorded and an error is emitted for the logs.


git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22825 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Correct alias and def/use analysis for *SVEC* primitives 

[reviewed by tom] 

r22606 fixed a bug where defs of aliases to records fields were not identified
as defs of the record itself. This patch is related as it fixes the same case
for homogenous tuples (which are implemented as records.) Defs to aliases of
tuple's fields were not being identified as defs of the tuple itself. The
reason for this is because of tuples being deffed/used through
PRIM_GET_SVEC_MEMBER and PRIM_SET_SVEC_MEMBER. After the pass
returnStarTuplesByRefArgs the PRIM_GET_MEMBER is turned into
PRIM_GET_SVEC_MEMBER. This turns something like PRIM_GET_MEMBER(record, x1)
where record and x1 are symExpr into PRIM_GET_SVEC_MEMBER(record, 1) where
record is still a symExpr but 1 is an integer literal representing that the
field is at an offset of one. 

This meant that for alias analysis something like 

callExpr = PRIM_GET_SVEC_MEMBER (record, 1)

would report that callExpr aliases 1 instead of the reality that callExpr
aliases the records first field. 

This patch updates alias analysis to handle this correctly as well updates the
def/use section so that PRIM_SVEC_SET_MEMBER identifies the def of the actual
field as well. 

This bug existed mostly because I had no clue that the svec primitives second
argument was an integer literal instead of the actual field. I'm kind of
surprised this wasn't an issue previously. 

A helper function was added to get the symbol of the field from a svec
primitive call. It might be useful to move that to a more central location in
the future. 



git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22826 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Updating futures for dynamic dispatch on iterators

Updating both of these futures with a bit more information.  Dynamic
dispatch on iterators seems to work when a variable has inferred type
and the initializing expression has a clear type.  For example, in
jturner's future, removing the static type declaration of the parent
class type causes the test to work as expected.  Vass's case shows
that removing the declared type is not sufficient though (I tested
this by moving the conditional assignment into the initializer and
removing the static type -- the test still failed in that case).

Interestingly, it's not quite as naive as the variable needing to
have a single runtime type because if I add a GrandChild class to
jturner's test and re-assign the variable to a new GrandChild(),
I get the proper invocation of the grandchild's iterator.



git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22827 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Adding the working variation of jturner's test that I described in my
previous commit



git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22828 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Make distribution assignment use the new signature. [reviewed by kyleb]

Upgrade assignment for distributions to use the new signature:
 - LHS has ref intent
 - return type is void.

The assignment contains two functional cases.  If the implementation (_value)
in the record-wrapped type is nil, then it is initialized by creating a new
copy of the RHS.  Otherwise, the reference count of the RHS is incremented.
In either case, the value of a is reprivatized.

In the first case, the new signature requires that a be updated directly,
rather than a new distribution object being created and returned.  I first
tried to use PRIM_ASSIGN for this purpose, but ref intent is discarded from the
arguments of RWTs when they are unwrapped.  

So I used PRIM_MOVE instead.  PRIM_MOVE handles the case of baseType -->
baseType copies in codegen, while PRIM_ASSIGN only handles the baseType -->
ref(baseType) case.  Adding other levels of indirection to the codegen for
PRIM_ASSIGN is left as pending task.

Once that is done, since RWTs behave as if they are references, there is no
harm in removing the return statement.  This brings the signature of 
  proc =(ref a: _distribution, b: _distribution) 
into line with the new standard.

[tested on / (std)]
[tested on domains/ distributions/ multilocale/ performance/ (gasnet)]


git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22829 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Update information about the task call stack size.

[Reviewed by Vass.]

This udpates the README documentation regarding the task call stack
size, how to set it, and a bit about what circumstances might call for
setting it.


git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22830 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Change non-identical record equality futures to "feature request"

These should have been changed to "feature request" with the last
release when we disabled default record equality functions that took
non-identical records.



git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22831 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Upgrade tuple assignment to the new signature. [reviewed by ]

Following r22826, it is possible to remove the return statement from 
   inline proc =(ref x: _tuple, y: _tuple)
without evoking any regressions.

Prior to that commit, alias tracking failed to recognizing that tuple elements
were being updated, because the second argument to a member access in a star
tuple is an integer (field index) rather than a field name.  The fault in alias
tracking allowed tuple assignments to be hoisted out of a loop, leading to
incorrect results.  However, this fault was only revealed after the return
statement was removed from tuple assignment, because the compiler-inserted move
(for assignments returning a value) formerly prevented that hoisting.

The removal of the return statement results in one fewer get and put per cycle
in the performance tests remote-tuple-write-1 and remote-tuple-write-small-1,
so the .good files were updated to reflect this improvement.

[tested on / (std)]
[tested on domains distributions multilocale performance (gasnet-everything)]


git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22832 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Retired classes/vass/subclass-cast-error.future and adjusted the expected output.

As of r22380, this cast (c:D below) should and does produce 'nil':

class C{};
class D:C{};
var c = new C();
var d = c:D;


git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22833 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Use jenkins url instead of crontab schedule when running nightly in jenkins land.

Smoke tested against `night -cron -hello`.

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