Open RobSpringer opened 2 years ago
what about a "reinterpret_cast" type operation for arrays? like you can reinterpret any array into a flat bitvector or vice versa. I think that would be more flexible (e.g. it could also express some kinds of reshapes).
That seems like a good way to do this. (Although I think that I've run into issues with array-casting altering the expected bit order of the underlying data or something like that, so it might be necessary to define a special sort of cast, but nonetheless, that's probably the best model to use, at least at the IR level.)
I think it makes sense to add sugar in the frontend to avoid users having to think of things in that way, though.
Agree that an IR-level cast might be a good way to handle this. We'd just have to define a reasonable mapping between types. Hopefully that would match up with the DSLX-level cast so lowering is easier. Right now casting an array of size N at the DSLX level lowers in N IR operations.
The application I'm working on needs a sliding-window-type thing, and the tools I have right now to operate on that are not great. Currently to do this, I need to do N array update operations (where N is the size of the array). Assuming the shift is a constant, then conceptually, it seems like this would lower to just a set of wires, i.e., be "free", whereas I'm worried that N updates would lower to a heck of a bunch of ops, or at least an excessive number of wires or temporary values.
We should consider implementing a first-class array shift op if this is a common enough operation.