E.g. the following silently computes nothing and fails the test:

#include "Halide.h"

using namespace Halide;

int main(int argc, char **argv) {
    Var x;
    Func output;
    Param<uint16_t> value;
    value.set(1);

    output(x) = value;

    Param<int> factor;
    factor.set(0);

    output.parallel(x, factor);
    
    const int sz = 1024;

    Buffer<uint16_t> buf(sz);
    buf.fill(0);
    output.realize(buf);
    for (int j = 0; j < sz; j++) {
        if (buf(j) != 1) {
            printf("output(%d) = %d instead of %d\n", j, buf(j), 1);
            return 1;
        }
    }

    return 0;
}

This sort of thing can come up when you have a complex expression for determining the split size and it's (unintentionally) sometimes zero. I believe it turns into a no-op because we defined division by zero to return zero.

Perhaps we should catch this as an error. Split factors depend on params alone, so they could be checked at pipeline entry. We could also consider just wrapping an implicit max(1, ) around every computed split factor (i.e. defining what it means to split by a factor of zero separately to what it means to divide by zero).

I'm going to tag this as a bug, because it's a schedule that silently produces the wrong output. It's more of a missing-error-message class of bug than a miscompile though.