It appears that for the programmer to understand how to organize the loops, it is a prerequisite to understand what type of loops Halide may generate in the first place?

As demonstrated, the compute_at function allows the programmer to tell Halide at which loop to insert a computation, so that the programmer can maximize producer-consumer locality. Here, the programmer wants to compute the necessary elements of blurx for just the loops within the loop with x as the iterator variable.

For this slide and the previous slides we are moving blurx around, is there a way for halide to determine where blurx should be and pick the optimal loop it should be nested in

When comparing this slide to the previous slide, is the computation in this slide more efficient? In the previous slide, for every tile with 256 * 32 pixels, we are computing 3 values of blurx per pixel. In total, that is 3 * 256 * 32 values of computation. However, since we are computing the values of blurx per tile first and then using them, adjacent pixels that share the same values for their blurx computation can simply just use them instead of having to compute them again. For example, out(1, 1) uses blurx(1, 0), blurx(1, 1), and blurx(1, 2) and out(1, 2) uses blurx(1, 1), blurx(1, 2), and blurx(1, 3), so in this approach blurx(1, 2) is only computed once for both values of out whereas it is computed twice in the previous slide.