Accesses inside indexing expressions should be in compute bounds

[alexreinking]

This is a bit of a loose thought, but I'm wondering how bounds inference handles cases like this:

h(x) = 10;
g(x) = sin(x); // whatever
f(x) = g(h(x));

h.compute_root();
g.compute_root();
f.split(x, xo, xi, 8, TailStrategy::RoundUp);

f.realize(10);

It seems to me there might be a hazard with h(x) being uninitialized between x = 10-15, unless accesses inside index expressions are required to be in the compute bounds (so the mem bounds of f become the compute bounds of h) - is that how BI actually works?

I couldn't find a case (at least during POPL paper crunch) to actually test this because the compiler is a bit too smart about inlining.

[abadams]

This segfaults for me inside the generated code:

#include "Halide.h"

using namespace Halide;

int main(int argc, char **argv) {
    Var x;

    Func f, g, h, out;

    const int min = -10000000;
    const int max = min + 20;

    h(x) = clamp(x, min, max);
    // Within its compute bounds, h's value will be within
    // [min,max]. Outside of that it's uninitialized memory.

    g(x) = sin(x);
    // Halide thinks g will be accessed within [min,max], so its
    // allocation bounds will be [min,max]

    f(x) = g(h(x));
    f.vectorize(x, 64, TailStrategy::RoundUp);
    // f will access h at values outside its compute bounds, and get
    // garbage, and then use that garbage to access g outside of its
    // allocation bounds.

    out(x) = f(x);

    h.compute_root();
    g.compute_root();
    f.compute_root();

    out.realize({1});
    return 0;
}

[abadams]

g is stack allocated, so I had to make min negative to get it to go to a bad address.

[abadams]

Proposed fix: When a Func f accesses a Func g using an index which depends on any way in some third Func h, and h is not compute_at within f's produce node, and the schedule for f uses RoundUp or ShiftInwards, and the FuncValueBounds of h are smaller than the bounds of the type of h, then we should either:

1. Throw an error
2. Inject a clamp around the call to h to clamp the loaded value to the FuncValueBounds so that FuncValueBounds isn't lying.

[alexreinking]

and h is not compute_at within f's produce node

This is because h's compute bounds cover all the points touched in f's loop bounds even though they technically don't have to, right?

[abadams]

Correct. If in future we managed to give h tighter bounds that than we'd have to relax the condition.

[alexreinking]

If in future we managed to give h tighter bounds that than we'd have to relax the condition.

Cool - it's worth having that documented in our conversation here.