Add peephole optimization to remove ref temps
Add a check for FLAG_WIDE_CLASS in PRIM_ASSIGN codegen
Adjust location of canRemoveRefTemps call

canRemoveRefTemps was being called on functions after their nested
functions were inlined. This would cause ref temps to be removed when
they shouldn't have been.

Also fixed a small check in codegen related to FLAG_WIDE and
FLAG_WIDE_CLASS.
Update ref temp removal code to deal with original vars that are refs
Copy a case in codegen from PRIM_MOVE to PRIM_ASSIGN (for no-local)
Change test_nested_var_iterator3 into a bug future

From test_nested_var_iterator3.future:

Bug: Copy propagation can not follow references through record fields

This test started to fail after 4160bf4 (Add peephole optimization to remove
ref temps). The actual failure is due to copy propagation not being able to
follow references through record fields. If this test is run with scalar
replacement, it works correctly since the record fields will be extracted.
Removed canReplaceRefTemps from FnSymbols

Based off Elliot's feed back I removed canReplaceRefTemps from FnSymbols
and instead pass a vector through inlineFunctions that indicates if ref
temps can be removed for that function. Made a small clean up to
callDestructors as well.
Bumping version number to 1.10.0 in anticipation of next release.

This mostly copies the changes from 220b0f6.
Add a few more checks and comments related to ref temp removal
Merge pull request #199 from Kyle-B/ref-temp-peephole

Add an optimization to remove ref temps when possible

This changeset makes inlineFunctions remove reference temps when possible. "Possible" is defined as any call that is a primitive or only contains primitive calls. While not perfect, this does remove ref temps for simple things like =, +=, *=, etc.

test_nested_var_iterator3 has been turned into a bug future in the pull request. A limitation in copy propagation was exposed by my changes, Tom is aware of this and said he will look into it.
Make the memoize decorator pass through kwargs

The old memoize didn't handle key word arguments at all, this version
will call the function correctly, without any caching happening. If it
proves to be necessary in the future, it shouldn't be too hard to add the
caching in for the kwargs form as well.
Fix previous attempt to get the lcd architecture for chapel modules

Not only do we need to get the lcd in printchplenv, the other chplenv scripts
that look for the existence of files in the gen directory need to use it as
well.

Note that even in places that don't really need the lcd such as chpl_gmp I
still changed it because it would be a source of confusion if for instance we
defaulted to our regular gmp defaults on cray instead of using system..

I noticed this on an xe where it couldn't find the right gen path because it
detected re2 was none because it was looking in a gen directory for the current
arch instead of the lcd one.
Add a more detailed note about when to use get_lcd to make it easier for people
needed to use chpl_arch in the future.
Merge pull request #216 from Kyle-B/chplenv-memoize-kwargs

Make the memoize decorator pass through kwargs

The old memoize didn't handle key word arguments at all, this version
will call the function correctly, without any caching happening. If it
proves to be necessary in the future, it shouldn't be too hard to add the
caching in for the kwargs form as well.
Merge pull request #215 from ronawho/moduleLCD

Fix previous attempt to get the lcd architecture for chapel modules

Not only do we need to get the lcd in printchplenv, the other chplenv scripts
that look for the existence of files in the gen directory need to use it as
well.

Note that even in places that don't really need the lcd such as chpl_gmp I
still changed it because it would be a source of confusion if for instance we
defaulted to our regular gmp defaults on cray instead of using system..

I noticed this on an xe where it couldn't find the right gen path because it
detected re2 was none because it was looking in a gen directory for the current
arch instead of the lcd one.
Make qthreads our default tasking layer

I believe we have all the correctness and performance regressions out of the
way and we are ready to switch to using qthreads as the default tasking layer.

This makes that change for all cases except arch == knc or platform == cygwin

This does NOT update our testing scripts. For tonight we will have multiple
machines testing the same configurations. This switch is to see if there are
any surprises or if anything with qthreads blows up. If it does it's likely
we'll just back it out.

If everything goes well, I'll update the testing scripts tomorrow. As a
temporary measure to make sure gasnet testing goes well, this just copies
setting oversubscription and turning off affinity in gasnet common.

Lastly this turns the previous scripts that were testing qthreads performance
alongside fifo to now test qthreads+tcmalloc. Eventually they should be testing
fifo, but we want to get some performance numbers for tcmalloc.
Merge pull request #217 from ronawho/qthreads-as-default

Make qthreads our default tasking layer

[reviewed by @Kyle-B]

I believe we have all the correctness and performance regressions out of the
way and we are ready to switch to using qthreads as the default tasking layer.

This makes that change for all cases except arch == knc or platform == cygwin

This does NOT update our testing scripts. For tonight we will have multiple
machines testing the same configurations. This switch is to see if there are
any surprises or if anything with qthreads blows up. If it does it's likely
we'll just back it out.

If everything goes well, I'll update the testing scripts tomorrow. As a
temporary measure to make sure gasnet testing goes well, this just copies
setting oversubscription and turning off affinity in gasnet common.

Lastly this turns the previous scripts that were testing qthreads performance
alongside fifo to now test qthreads+tcmalloc. Eventually they should be testing
fifo, but we want to get some performance numbers for tcmalloc.
Merge pull request #214 from thomasvandoren/version-1-10

Bumping version number to 1.10.0 in anticipation of next release.

This mostly copies the changes from 220b0f6.

reviewed by @bradcray and @vasslitvinov
Temporarily set CHPL_RT_CALL_STACK_SIZE=2M for linux32 builds

Qthreads preallocates stacks for 128 threads up front and our large stack size
of 8M means we have over 1GB allocated right away which causes segfaults for
linux32. This is meant as a temporary measure so that we can get some testing
in for qthreads still.
Merge pull request #218 from ronawho/qthreads-as-default

Temporarily set CHPL_RT_CALL_STACK_SIZE=2M for linux32 builds

Qthreads preallocates stacks for 128 threads up front and our large stack size
of 8M means we have over 1GB allocated right away which causes segfaults for
linux32. This is meant as a temporary measure so that we can get some testing
in for qthreads still.