[RFC] Continuing with bufferization::{TensorLike, BufferLike} - op semantics update in bufferization

[andrey-golubev]

@matthias-springer

@andrey-golubev

and maybe eliminate op-level interfaces methods e.g. BufferizableOpInterface::getBufferType

I think you’re still going to need that. This function is predicting the future buffer type for a tensor result. E.g., for tensor.extract_slice, the bufferized result must have a certain layout map. We need to predict this type when bufferizing a loop op: if I remember correctly, the loop op is bufferized before the loop body.

I see. So the BufferizableOpInterface::getBufferType is a building block of BufferizableOpInterface::bufferize kind of and simultaneously the method to preliminary query the output buffer without actually bufferizing. I guess the renewed logic is then something like:

• Try BufferizableOpInterface::getBufferType if op supports BufferizableOpInterface
• Go to “new getBufferType API” otherwise

(the cases could likely be enclosed into the free-standing getBufferType function or something along these lines)

@matthias-springer

Inside of BufferizableOpInterface::getBufferType, the builtin MemRefType can be hard-coded.

Do you mean at API level or in implementation? I guess the latter does make sense indeed. I’d still prefer BufferLikeType BufferizableOpInterface::getBufferType(TensorLikeType, ...) at the signature level though.

@matthias-springer

What’s the difference? The first one is a member function, the second one is a static function? What is smth?

Yes. Member function - clear enough (again, main concern is that we couple “types” and “operations” on these types). Non-member function:

• bufferizationOptions.getBufferType(TensorLike) → BufferLike (smth - options object)
• converter.getBufferType(TensorLike) → BufferLike (smth - some converter object that is a DialectInterface that one just creates for user-specified tensor/memref - they likely live in own dialect anyway)
  • this has to live inside the context forever though (so slightly higher memory usage)

From the standpoint of custom tensors / memrefs support, options is probably most cumbersome because they require one to basically reimplement one-shot-bufferization pass itself (not the underlying mlir::runOneShotModuleBufferize() function with the actual logic though) - because that’s the only way to “seed” options object? For instance, this is what we do in our downstream and it works fine, I am not against this in general.