Views and underlying array being used together
Closed this issue · 6 comments
More views complications. Consider this program:
view v_a = a[i! :];
---
v_a[10]; a[20];
Fuse will happily mark usage of the second access to a as correct because it considers v_a to be "just an array". Looks like view creation needs some more complicated logic for safety...
This came up in the PolyBench example:
// Sigh, a suffix view doesn't work here...
for (j = i; j < _PB_N; j++) {
w = A[i][j];
for (k = 0; k < i; k++) {
// Because one of these will be a view and
// another one will be the underlying array.
w -= A[i][k] * A[k][j];
}
A[i][j] = w;
}It is possible to write a program where we are using a suffix view. Unfortunately, that requires us to reorder the k and j loops and move the A[i][k] access out from the inner loop.
Indeed. I think we need the type checker to "remember" that the parts of a that were consumed at view creation stay consumed until v_a goes out of scope. It's not too different from a really simple version of "borrowing" in Rust—as long as v_a exists, it has "borrowed" part of a.
oh no, not a borrow checker.... /s
In the example, it seems like we want a different behavior entirely: v_a and a can be used in separate pipeline stages, but never together. If we create the restriction that a cannot be used while v_a is in scope, we do get safety, but it seems like it would produce very convoluted code.
Yeah, this example is hard. The idea that you'd want to use a view and the original array (or, more generally, two views on the same array) in different pipeline stages is really not what I was imagining until seeing this example—I would have hoped that the mutual exclusion afforded by view consumption would be more "lexically scoped" than that. Seems like we need to think about this more…
The never ending nightmare of views continues...
Some thoughts about what views mean/how to resolve this issue: