Build fewer LLVM components to speed compile

This patch significantly reduces the build
size and the build time. It omits some LLVM
and Clang components we don't use and only
builds host and x86 and x86-64 backends.

Used to take 23 minutes, now takes 18 minutes
to CHPL_LLVM=llvm time make on my machine. In
addition, llvm/build is now 8G (was 12G)
and llvm/install is now 4.6G (was 5.8G).
Lower the problem size for test_many_domain and test_many_array

Since switching to qthreads these tests take a lot longer to execute and
test_many_domain times out pretty often. test_many_domain has also been timing
out for numa+gasnet for months

This doesn't reflect a real problem with qthreads, so much as it does a
"problem" with the testing framework. Even with qthreads configured with
oversubscription and affinity off there is still interference from multiple
qthreads instances running on the same machine.

I tested these two programs out on an xc and on a cluster, and the qthreads
version was a few seconds quicker so I'm pretty confident in my claim that it's
just how we test gasnet+qthreads that's responsible for the slow down and not
some performance mystery that needs to be explored.

These new sizes lower the execution time to ~30 seconds.
Merge pull request #311 from ronawho/qthreads-timeouts

Lower the problem size for test_many_domain and test_many_array

[trivial, not reviewed]

Since switching to qthreads these tests take a lot longer to execute and
test_many_domain times out pretty often. test_many_domain has also been timing
out for numa+gasnet for months

This doesn't reflect a real problem with qthreads, so much as it does a
"problem" with the testing framework. Even with qthreads configured with
oversubscription and affinity off there is still interference from multiple
qthreads instances running on the same machine.

I tested these two programs out on an xc and on a cluster, and the qthreads
version was a few seconds quicker so I'm pretty confident in my claim that it's
just how we test gasnet+qthreads that's responsible for the slow down and not
some performance mystery that needs to be explored.

These new sizes lower the execution time to ~30 seconds.
Merge pull request #292 from mppf/llvm-faster-build

Build fewer LLVM components to speed compile

This patch significantly reduces the build
size and the build time. It omits some LLVM
and Clang components we don't use and only
builds host and x86 and x86-64 backends.

Used to take 23 minutes, now takes 18 minutes
to CHPL_LLVM=llvm time make on my machine. In
addition, llvm/build is now 8G (was 12G)
and llvm/install is now 4.6G (was 5.8G).
Adding some error message futures.
Merge pull request #313 from sungeunchoi/test

Adding some error message futures.
Allow C for loop operators to be user defined

Converts c for loops from:
  __primitive("C for loop", i, start, end)

to:
  __primitive("C for loop", initExpr, testExpr, incrExpr)

where init, test, and incr are either primitives or symExprs

This allows the relational operator to be user defined instead of forcing C for
loops to use <=.

To allow this we just update build.cpp to wrap the init, test, and incr exprs
with block stmts instead of buildling the init, test, and incr out of the
previous form and updating ChapelRange to create the init, test, and incr exprs
in the iterator.

Adds a function to AstUtil to check if a call is a relational operator and uses
that at codegen time to make the check for a relational operator reusable and
not just coded in codegen for c for loops.
Use c for loops in more range iterators

Use C for loops for unbounded ranges, and bounded/strided ranges.

This also adds an iterator to use when you know the stride is positive.
Currently the use must call this iterator themselves and it is used in an
optimized case for DefaultRectangular.chpl iterator.

I think it would be ideal if the stridable was an enum that was either
negative, positive, unknown, or none and then we could provide these optimized
iterators that would get used in a lot of other places. However, stridable is
used all over in ChapelRange, DefaultRectangular, ChapelArray, and all the
distributions so it would take a while, and I'm not 100% is possible yet. Plus
it would limit the by operator...
Clean up range iterators and switch to += and assign

Cleans up the iterators using C for loops in ChapelRange.

Also adds multiple user defined c for loops to userCForLoops tests that test
opEqual and nonOpEqual versions as well as some other relational and increment
operators
Clean up loop in DefaultRectangular and update comment