LLVMHeaders.h needs to re-define NDEBUG if it undef's it (Issue #160)
Attempting to fix the syscall numbers for clock_gettime
Some os x linker fixes for the runtimes.
Bugfixes to bounds inference and sliding window.

There's a remaining problem with inferring storage bounds taking forever.
To trigger, run interpolate app with HL_TARGET=ptx.

Sliding window was doing completely the wrong thing when sliding backwards.
Made tracing test tolerant of reordered loads
Adding missing #include to tracing_stack test
BufferContents constructor that takes a buffer_t wasn't initializing allocation
Fix bug in bounds inference

We were early-simplifying min and max incorrectly.
fix for test_code_explosion

Bounds inference caused a code explosion again, probably due to the bugfix
commit before this one. Solved via explicit CSE during bounds inference.
Not a good solution. Really need graph-aware bounds inference instead.
Added a boundary condition to interpolate to speed it up.
Added a test for a bug found by the autotuner.
Changed width/height/channels to return one for low-dimensional buffers.

We view color images as three-dimensional arrays. So when you ask for the
channel count of a two dimensional buffer, that's short-hand for asking
for the extent of the buffer in dimension 2, and if you ask for the extent
of a buffer in a dimension beyond its dimensionality, that's an error.

This is confusing behavior. Given that width, height, and channels calls
are sugar for a convention, I've made those calls return one for buffers
of fewer than the appropriate number of dimensions. The Image::extent
call retains its old behavior.
Fix bug in bounds of select node.
Added ability to run any or all tests under valgrind.
Continuing to mess with bounds inference to fix autotuning bugs

We're not there yet, but this checkpoint is only a little bit broken
and only a little bit slow, and I believe it's better than what's currently
checked in.

HL_TARGET=ptx interpolate is slow because storage inference operates
inside-out and considers both calls and provides.

Some schedules may cause uncaught out-of-bounds reads on inputs, because
the current bounds inference logic does something awkwardly in between
checking what will be loaded and checking what is necessary for a correct
output.
Bounds inference overhaul

Changed the way splitting clamps so that storage bounds can be computed
from first principles, instead of recursively sniffing the IR. Now it clamps
to be within the bounds realized (the bounds at the store_at level), whereas
previously it clamped to be within the bounds produced (the bounds at the
compute_at level). There's only a difference when you store_at outside the
compute_at, and the compute_at region required is smaller than the minimum
region that can be computed due to splitting/vectorization. It's a corner case,
to be sure, but the autotuner was having a field day there. This fixes
the slowness of the last commit in this series. Interpolate with HL_TARGET=ptx
went from 2 minutes to 6 seconds, most of which is actually running and
benchmarking.

Now at every loop level we track bounds required and bounds produced for each
function. The bounds required come from sniffing the lowered IR pre-bounds
inference. These will be expressions in the bounds produced of later pipeline
stages. Bounds produced are the bounds required rounded up slightly.

They get rounded up to (A) at least the size of the outermost split in the
produce step, and then get rounded up to (B) a multiple of the outermost
split used in any reduction stage.

(A) is necessary because when we split, the inner dimension must be the
size promised (in case we're vectorizing). We can make multiple instances
of the inner loop overlap though, (e.g. compute elements [0 1 2 3], then
[2, 3, 4, 5]). (B) is necessary because we're not allowed to do the
overlapping trick with reductions. Updating at a pure var multiple times
without reinitializing that site will produce the wrong result.

If we're inside the store_at level, the min produced then gets pushed
downwards so that it does not escape the realization. Outside of the
store_at level, we make sure we don't escape the bounds produced one
loop level up. I.e. we expect that the bounds produced at each loop level
are strictly contained within the bounds produced at all outer loop levels.

The whole point of this commit was to infer the bounds allocated more easily.
The bounds allocated are now just the bounds produced at the store_at level,
expanded to cover the memory locations hit by any update step (in case we're
scattering stuff out of bounds).

Now that we distinguish between bounds required and bounds produced all
through compilation, bounds inference is on a much better footing for
future changes.
Initial changes to have Halide only infer implicit arguments when requested.

Previously, Halide would infer extra arguments werever the ended up
being needed. This is convenient but turns out to cause a lot of very
difficult to track down compilation errors. This commit makes it so
inferrence only happens when a placeholder ('_') appears in an
argument list or where a Func is used with *no* argument list at
all.

E.g. where:
    f() = g() + h();
used to be valid for any number of arguments to g and h, now one must write:
    f(_) = g(_) + h(_);
to get the same behavior. (The former style now gives a warning and will
ultimately become an error. See HALIDE_WARNINGS_FOR_OLD_IMPLICITS macro.)

The placeholder does not have to appear at the end of an argument list.
E.g. the following:
    f(_, c) = in(_, 0) * c_red + in(_, 1) * c_green + in(_, 2) * c_blue;
is a dot product across an RGB image for an arbitrary number of
dimensions, so long as the last one is the channels dimension

If there is no argument list at all, e.g. the empty parentheses do not
appear, argument inference will occur, as it did previously. That is
an unadorned "f" is equivalent to "f(_)" rather than "f()".

Implicit arguments now have names of the form "_0", "_1", etc. Before
these were "iv.0", "iv.1", etc. The first ten are predeclared in Var.h
to allow use in scheduling, though there may be some danger in this
because if they are used in user written code, errors will occur
because names of this form are treated specially during compilation.

This should be ready for evaluation. I am planning to work on giving
inferred arguments the variable names used in the code instead of the
synthetic ones (_0, etc.) in situations where the all uses of an
inferred argument are in Func call slots that have the same formal
parameter name.
Bounds of cast is more conservative/correct now.

It tries to prove there's no overflow instead of just assuming it.
Adding test to previous commit.
Added a check for implicit casts that change meaning.

E.g:

cast<uint8_t>(x) % 256

now errors, instead of converting to

cast<uint8_t>(x) % 0