Iterators: Revise the test for determining if a SymExpr is in a loop header to handle new representation
Merge pull request #954 from noakesmichael/baselineFix

The code for lowering iterators included a subtle check to determine whether
a symExpr is contained in the header of a loop.  Unlike similar tests it relied
on the overall shape of the code above the SymExpr rather than the more
common reliance on the call-type of the blockInfo.

For the short term I have updated the test to (a) match the new
shape (b) be slightly more robust (c) added a tagged comment
so that I can come back and improve this test when the Loop
work is more sound.

Compiled: STD clang/darwin, STD gcc/linux64, LLVM gcc/linux64
Tested: paratest --baseline and standard paratest
Review: None
Initial attempt to optimize anonymous range iteration

When iterating over a range such as:
  for i in 1..10 do ...

we end up constructing a range and then getting it's low and high values out.
The range creation adds additional overhead that is not needed and it
obfuscates the loop from the backend compiler (it probably can't figure out how
the number of iterations even though the chapel compiler knowns it at compile
time.)

Ideally we want to generate
  for i in 1..10
as
  for(i=1; i<=10; i+=1)

This removes the construction cost, and should allow the backend compiler to
optimize/auto-vectorize better.

To accomplish this, this work replaces anonymous ranges with direct iterator
calls in for loops. Ranges are iterable because they have a these method. This
replaces the range with a direct call to an iterator. It essentially replaces
the code:
  for i in 1..10
with:
  for i in _opt_range_iter(1, 10)

the end result is that
  for i in 1..10
is now generated as:
  int64_t i;
  for (i = INT64(1); ((i <= INT64(10))); i += INT64(1)) {}
which is exactly what we wanted

This also handles anonymous ranges whose stride is known at compile time

E.G it handles
  for i in 1..10 by 2

and it will call into a more optimized iterator

if the stride is not known at compile time we don't do anything because we need
the range iterator to use chpl__diffMod

Not that this does nothing for aligned ranges, and doesn't handle cases such as
for i in 1..10 by 2 by 2 since it doesn't seem like a common case

The first attempt to do this was to replace the entire for loop with a c for
loop directly, but you can't do that for zippered iterators and figuring out
the type of the stride is really difficult and you have to insert calls to the
overflow checking and the general iterator.

A better long term solution might be to expand scalarReplacementOfAggregates to
includes ranges. That would allow all ranges to be optimized, including
non-anonymous ranges, and ranges that are used in contexts other than direct
iteration.

I still need to clean up the direct iterators, and make use of them from other
iterators. I also need to add bounds checks and the general iterator around it.
Update elimination of range constructors for anonymous range iteration

Add bounds checking (kind of hacky for now) and call to general iterator if
optimized iterators are not being used.

Should replace anonymous range iteration for most simple ranges (including
zippered)

for i in 1..10
for i in 1..10 by 10
for i in varA..varB
for i in varA..varB by paramA
for (i, j) in zip(1..10 by 2, 1..10 by paramA)

If the range is aligned, or has multiple by's applied to it or the types don't
match then a non-anonymous range is created and iterated so that there don't
have to be a ton of versions of the _direct_range_iter.
Add different versions to support  arg coercion (like is done for build_range)
Swap the order of the iterators to separate them in a more logical manner

Also adds an all int param version of the iterator because it produces the
cleanest loops.

e.g. 'for i in 1..10' turns into 'for (i=1; i<=10; i+=1)' with no temp
variables
Fix general iterator
Comment out all param iter and add TODOS
Strengthen check for bounded iterator and add zippered iter check

Need to be sure this optimization only fires for bounded iterators. Currently
it fired for bounded and unbounded. The check to do so should be strengthened
more. Also when looking at the iteratorExpr we looked for a tuple so that we
could replace ranges in a zippered iterator. However, this also fired for non
zippered iterators over tuples, which we didn't want to do.