Add support for writing out lowered .stmt form of Halide code for
debugging and schedule analysis.
Add a header file for user visible overridable and callable routines
in the Halide runtime. Purpose is two fold: to give prototypes for
overriding and calling these routines and to provide Doxygen
documentation on them.
blur no longer requires HL_DISABLE_BOUNDS_CHECK
Slightly more debugging output in Bounds.cpp
Resoect constraints when defining bounds of the output.
Added ability to query pipelines about bounds inference information.

If you pass in a buffer with a host and dev pointer of NULL, instead of
running the pipeline it will populate that buffer with appropriate sizes,
strides, and mins. It attempts to satisfy both the required region and
also any constraints. It also respects expansion due to vectorization, etc.

It does this by computing the required region, then passing it through the
constraints, and then checking the bounds again. This can be tricky with
recursive constraints. Say you have a constraint that the width must be a
multiple of four. If you want to use this feature, you should express your
constraint like so:

im.set_bounds(0, 0, ((im.extent(0)+3)/4)*4);

Note that passing a required extent through this expression will round it
*up*.

Doing the following:

im.set_bounds(0, 0, (im.extent(0)/4)*4);

will trigger an error during the bounds inference phase, because it will
compute the required extent, round it down to the nearest multiple of four,
and then do the bounds check again. Constraining things to be constants,
which is the common case, will work fine (and will check those constants
against the required regions for you).

In some cases the inference routine will give you results that won't pass
the constraints (or the bounds tests), and it also won't throw an error until
runtime. For example:

im1.set_bounds(0, 0, im2.extent(0));
im2.set_bounds(0, 0, im1.extent(1));

If you're doing simultaneous bounds inference for im1 and im2, this will
set the width of im1 to the required width of im2, and the width of im2
to the required height of im1. The width of im1 and im2 probably no longer
match after this, so the first constraint will fail when you run the pipeline.

Solving this problem in the general case requires solving arbitrary systems of
nonlinear equations (or statically proving that there is no solution). You
can, for example, encode a constraint that provides a counter-example to
Fermat's last theorem. Bounds inference isn't going to disprove Fermat's last
theorem for you by finding a solution. It's not even going to try.
Merge branch 'master' of github.com:halide/Halide
Rationalize the x86 targets:
-- ensure that all x86 targets gave explicit 32 or 64 suffixes (rather than having x86 imply 64-bit)
-- x86-64 now doesn't assume SSE4.1 (or SSSE3), so is suitable for all x86-64 architectures; added a new x86-64-sse41 to support SSE4.1 enabled x86-64. (Note that we now enable SSSE3 instructions only when SSE4.1 is enabled; previously we assumed all x86 variants were SSSE3-capable, which made it impossible to support all x86-64 architectures)
-- added NaCl targets corresponding to every x86 target
-- revamped the runtime support files as necessary to match the new set of targets
-- added some smarts to tests/simd_op_check.cpp to skip checking ssse3/sse41/sse42 when not part of the target
Merge pull request #102 from steven-johnson/master

Rework x86 targets to allow for x64-64 without sse4.1, plus related changes (Issue #100)
Strip trailing whitespace in CodeGen_ARM
Makefile fixes

Targets for init mods now consistent with march() behavior in CodeGen classes.

Re-added arm_nacl to the list of targets built.
My compiler choked on the recursive macros when compiling with native client.
Updated build for HelloNacl to hit the correct x86 target names.

It builds but doesn't run right now.
More type checking on loads from images and image params.
Added an example of manually scheduling an RVar.
Added a performance test for fast_pow.
Updated Nacl instructions and Makefile.

Not defining NATIVE_CLIENT_<arch>_INCLUDE was causing really unhelpful errors.
Made some Func constructors explicit to prevent unintentional casting

This syntax, which we thought we had already disallowed:

Func f, g, h;
f = g + h;

Actually doesn't work now. Use:

f() = g + h

instead.
Added frees to the x86 test.
x86-32 and x86-32-sse41 working

A few tests that did floating point compares needed fixing