lukewagner
commented
10 months ago In theory, yes, it makes sense and seems complementary to what we were talking about in #194, and maybe belongs as part of the same feature.
Just to help me understand the motivation (and see if there's a short-term workaround): what's the reason for using a list<u8> instead of, say, a list<u64> (which would have essentially the same Canonical ABI as list<u8> except with the additional alignment check)? That would mean having separately-named "overloads" for list<u16>-vs-list<u32>-vs-list<u64>; is that the problem?
abrown
Over in wasi-nn, we have been wondering whether there might be a way to specify an alignment for a type larger than the one specified by the canonical ABI. This is similar to what @titzer brings up in https://github.com/WebAssembly/component-model/issues/194 but I thought it was different enough to merit its own issue.
wasi-nn currently specifies the tensor data as
list<u8>(WIT). The initial rationale (long ago, back in the WITX days) was a performance consideration: ML frameworks can deal with tensor data as byte blobs and if we can just "pass the bytes through" we can avoid some extra copies. This means that when we, as a wasi-nn guest user, receive tensor data back we must convert it somehow fromlist<u8>tolist<f64>, e.g. This conversion is an unsafe cast in some of the bindings — what if thelist<u8>is not aligned to cast tolist<f64>? There has been an outstanding issue (https://github.com/WebAssembly/wasi-nn/issues/27) to figure this out. One solution would be to always copy the data; another to conditionally copy the data only if unaligned; etc.The solution I'm asking about here is adding some way to inform the runtime of the alignment we would like when allocating space for the tensor data. Is this possible? Is it different enough from what @titzer is asking? I suspect we would only want to allow allocations for alignments larger than what the canonical ABI specifies, but maybe not.