Do not use CHPL_TEST_SF_PERF_DEST, instead rely on ssh configuration.

git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22595 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Stop treating {D} as D for a domain D

[reviewed by hilde]

For some time now, Chapel has permitted a domain to be specified either by
naming it, e.g.:

        const D = {1..n};
        const DistD = D dmapped Block(...);
        forall i in DistD ...

or by wrapping it in an extraneous set of curly brackets:

        const D = {1..n};
        const DistD = {D} dmapped Block(...);
        forall i in {DistD} ...

The reasons for this are somewhat obscure (and arguably indefensible), but
relate to (1) a precedent set in ZPL, (2) the days when we used square
brackets for domain literals, and (3) to the use of anonymous domains in
array declarations without curly brackets (i.e., a pure implementation of
Chapel would require:

        var A: [{1..n, 1..n}] real;

rather than permitting the shorthand:

        var A: [1..n, 1..n] real;


I'd forgotten about this anomaly until doing cleanup on iterations over
anonymous domains the other week when I encountered some instances of it.
Over lunch, Vass pointed out that cleaning this up should be fairly easy so
I took it on as a five-minute fix (TM).

This patch starts us toward a better world where we interpret {D} as an
associative domain of domain values, containing one index 'D'.  This seems
more consistent with the current language definition and was generally
agreed to be improved by the Chapel team.  I say "starts" because for now it
makes {D} into an error overload to help users with existing code transition
from the old world to the new.

The heart of the patch is a simple change:  We have traditionally supported
a routine, chpl__buildDomainExpr() which creates a domain from whatever is
passed it.  One of the overloads took a domain and simply returned it which
is what caused '{D}' to evaluate to 'D'.  So the idea behind this change is
to remove that overload (though again, for now, I simply replaced it with an
error overload while we're transitioning).

A little more work was required, however, because the same call is used to
build the domain for an array type like '[D] real' and in this case, we want
to permit a domain like 'D' to be used.  So what I did was to split this
call into two calls:


        chpl__buildDomainExpr() : does what it has, but making the domain
                                  case into an error overload for now

        chpl_ensureDomainExpr() : used in the array type signature context
                                  to make sure that the expression is a
                                  domain.  In this context, if the thing
                                  is a domain, we simply return it.  In
                                  all other cases, we forward the args to
                                  chpl__buildDomainExpr()

From there, the only other change was to switch calls to
chpl__buildDomainExpr() in the array type signature case (which was most of
them) over to chpl__ensureDomainExpr(), and to rewrite any tests that were
relying on '{D}' evaluating to 'D'.

For backwards compatibility, this commit generates an error message when
encountering {D} to tell the user about the change in interpretation that's
coming and to suggest that they remove the curly brackets.  In the next
release, by removing the first overload of chpl__buildDomainExpr() in
ChapelArray.chpl, we'll have the new interpretation.  Note, however, that we
don't yet support associative domains of domains, so disabling this overload
today results in a "we don't support this style of associative domain
yet"-style message.  But I think after the next release, we should still
remove this overload even if we haven't yet gotten around to fleshing out
associative domains of domains (which might be as simple as providing the
required hash function for domain values?)

I also added tests to lock in the error message for now.  Ultimately, these
could be used to test the associative domain of domains intepretation.

The bulk of the patch is just updating tests that had relied on this
syntactic form in the past.




git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22596 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Change precedence for | ^ & << >> .. in.

[reviewed by Tom, discussed widely]

Why? I learned recently that even the creators of C (or at least,
Dennis Ritchie) think that the bitwise operator precedence rules are wrong.
See
   http://www.lysator.liu.se/c/dmr-on-or.html

I did a little survey of languages.

The C way : C C++ Java Objective-C PHP C#, Javascript;
 in these languages, bitwise operations bind less tightly than ==.

FORTRAN: bit ops not in language exactly

GO: shift, bitwise and with multiply, bitwise or xor with +
Erlang: bitwise and with *; all others bitwise ops with +
Perl 6, Python, Ruby, Dart: all bitwise operators lower than + but before ==

In this patch, I modify the Chapel parser to:
 - make bitwise operators bind more tightly than comparison operators
   (so that x & MASK == 0 works as (x & MASK) == 0 and fixing the
    design problem we inherited from C)
 - give all bitwise operators precedence between + and *
   They are in one group because I think that's easier to remember.
   They have precedence near multiply since bit shifts can be
   viewed as multiply/divide by a power of 2.
 - make 'in' less tightly binding than 'align','by',#
   (although it seems not to matter because TIN is required in a specific
    place already by the grammar and not available in general expressions)
 - make .. more tightly binding than ==,<=,etc, so that
   1..10 == 1..10 works. The justification here is that ranges
   of bools are just not that interesting.

I updated several tests that exist to check precedences
    test/modules/standard/gmp/studies/gmp-chudnovsky.chpl
    test/performance/compiler/bradc/compSampler-timecomp.good
    test/expressions/bradc/bitopsVsEqualtyPrec.good
    test/expressions/bradc/bitopsVsEqualtyPrec.chpl
    test/trivial/deitz/test_all_precedence_levels_in_a_single_expression.good
    test/trivial/deitz/test_all_precedence_levels_in_a_single_expression.chpl
    test/trivial/shannon/compSampler.good
to believe the new behavior is right.

Only one test not testing precedence levels failed because of this change:
    test/modules/standard/gmp/studies/gmp-chudnovsky.chpl
had the line
  while (i<f.num_facs & j<g.num_facs)
which is almost certainly a type-o and which I updated to
  while (i<f.num_facs && j<g.num_facs)

These work both under the old and new rules:
  right-rotate: x >> 1 | x & 1
  left-rotate: x << 1 | x >> 63
  append bits to number: x << 7 | new_bits
  extract bit i: x & 1 << i

These work under the new precedence rules only:
  check mask set: if x & MASK == MASK
  check mask bit: if x & MASK != 0
  shift-as-multiply: 17 + x << 2 // ie same as 17 + x * 4
  check bit i: x & 1 << i != 0
  Compare ranges: 1..10 == 1..10 

Possible Further Discussion:
 - Should Chapel have so many precedence levels?
 - Do we have the right precedence of | ^ & ? 
 - Did we make the right choice about how bitwise
   operators combine with + or * ?

Future Work:
 - Update the specification/other documentation



git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22597 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Add support for expression-less 'serial' statement

[reviewed by lydia]

This commit extends the parser to permit 'serial do ...' or 'serial { ... }'
without the requirement to add an expression test.  The meaning is the
same as 'serial true ...'  In retrospect, I don't know why we didn't do
this years ago (maybe we didn't care enough).

Updated the spec to reflect this change and wordsmithed the serial
statement description while here.  Updated a 'serial true' test in
the spec to simply use 'serial'.

Updated my code that motivated this 5-minute fix (TM).



git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22598 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Add --fast back into perfcompopts files that had renamed .dat files without any additional options

[Informally reviewed in chat]

When --fast was removed from all of the perfcompopts files, a few of them had
been renaming the dat file for runs with just --fast. This caused the tests to
not run those configurations. For the time being, I've added --fast back into
these files.


git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22599 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Add a perf test for emitted code size [reviewed by ]

This adds a simple perf test and graph for emitted code size.

I added a counter in codegenStmt(), so the number of statements generated is
tallied.  This is printed out conditionally when fPrinEmittedCodeSize is true,
which is effected by tossing the --print-emitted-code-size compiler option.

The actual number of lines of C code generated will be somewhat larger, since
this count does not record the contents of the header file or function
signatures.

[Smoke-tested with hello.chpl]



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

[reviewed by Lydia]

This test does small serial reductions in a forall loop.  It times 3 different
styles (all inside parallel forall loops):

1. serial do res[i] = + reduce [j in 1..3] A[i][j]
2. res[i] = + reduce for j in 1..3 do A[i][j]
3. serial do res[i] = + reduce A[i][1..3]

Currently 2. is fastest because it uses a serial iterator instead of
serializing leader/follower iterators.


git-svn-id: svn+ssh://svn.code.sf.net/p/chapel/code/trunk@22601 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Fix testing log location for other tests.

r: hildeth, lydia-duncan

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