We’ve been using a std::vector<size_t>, would that work? (fwiw, in the tf_compile use case, which emitC would replace, we don’t even use that, we just bind by name and let testing catch invalid memory accesses.
Is the concern that we’d have an extra test burden on anything that’s not primarily interested in consuming EmitC? If so, we can use the ml-opt-* build bots to exercise all this - it’d both do integration testing like it does today - taking “some” model → tf_compile → use it; and it could do the more rigurous suite you’re mentioning.
Probably ok, so far we’ve modeled bools as int64_t anyway. Not saying it’s great, but this doesn’t sound like it’d break anything.
While here, on tensor assumptions, we basically have 2 main ones:
- we can bind by name
- we can use stable buffers that are in row-major order. By “stable” I mean that once EmitC object representing a model instance hands it, it doesn’t free it until the object is deleted. We’re OK with handing those buffers ourselves, fwiw (the benefit of letting the model hand them is that maybe it has preferences where to place them)
This lets us pay a higher upfront cost at binding time and then we just do simple stores in a buffer (no virtualization or anything) + eval (we can chat about this more)