For example, here is a sketch of a pipeline that does some padding, and then calls a function to produce an output, in tiles:
i = loop([0, 100], 10) {
out_i = crop_dim(out, 0, [i, i + 9]) {
in_padded = allocate(heap, /*elem_size=*/4, {{i - 1, i + 10}}) {
copy(in, in_padded, padding)
call(f, in_padded, out_i);
}
}
}
In a typical case for something like this, only the first (i = 0) and last (i = 90) tiles need padding. The rest of the tiles could just use an alias of the input.
We don't currently have a way of implementing this "optional aliasing". Some ideas:
-
We could use make_buffer instead of allocate, and pass 0 for the base pointer, i.e. make a buffer with no data. Later, if things operating on that buffer could either allocate the buffer, or re-assign it, that would enable this. The tricky part is: how to handle freeing the allocation. raw_buffer right now does not enable this easily (it has an allocate function, but it returns the pointer to be freed later. The slinky program has nowhere to store that pointer).
-
We could add some kind of loop partitioning, where we have 3 loops: a warm-up, steady state, and cool-down loop. The steady state loop could use aliasing for the padded copy, while the warm-up and cool-down loops would have an allocate + copy. This solution is a bit less general (I think there are cases where user defined callbacks might want to allocate their output buffer, not only copies).
For example, here is a sketch of a pipeline that does some padding, and then calls a function to produce an output, in tiles:
In a typical case for something like this, only the first (i = 0) and last (i = 90) tiles need padding. The rest of the tiles could just use an alias of the input.
We don't currently have a way of implementing this "optional aliasing". Some ideas:
We could use
make_bufferinstead of allocate, and pass0for the base pointer, i.e. make a buffer with no data. Later, if things operating on that buffer could either allocate the buffer, or re-assign it, that would enable this. The tricky part is: how to handle freeing the allocation.raw_bufferright now does not enable this easily (it has anallocatefunction, but it returns the pointer to be freed later. The slinky program has nowhere to store that pointer).We could add some kind of loop partitioning, where we have 3 loops: a warm-up, steady state, and cool-down loop. The steady state loop could use aliasing for the padded copy, while the warm-up and cool-down loops would have an
allocate+copy. This solution is a bit less general (I think there are cases where user defined callbacks might want to allocate their output buffer, not only copies).