masahi edited a comment on pull request #8463:
URL: https://github.com/apache/tvm/pull/8463#issuecomment-880346762
> On the other hand, one could argue that the type annotation should be
made independent from the type annotation that also shares with the usage site,
so we could let the allocation site contain a duplicated set of information and
check consistency during construction
I think if duplicated information are supposed to be consistent, then they
are already not independent. So I don't see an advantage in keeping track of
two essentially the same information.
To @jroesch's question, right now our code base uses two ways to create
`Buffer`:
1. Via `decl_buffer` function. Here, a buffer variable (with its
`PointerType`) is constructed at the same time as `Buffer`. So we can make sure
that two storage scopes agree (Although currently we don't pass `storage_scope`
to `Buffer` constructor).
https://github.com/apache/tvm/blob/main/src/tir/ir/buffer.cc#L48-L53
2. Via `Buffer` constructor directly, using a buffer variable already
constructed.
https://github.com/apache/tvm/blob/main/src/tir/ir/buffer.cc#L386-L388 Here, it
is possible to have a situation where the storage scope recorded in the buffer
variable is different from the one in `Buffer` constructor. In particular, if
the former one is empty while the latter one is non trivial scope (`shared`,
`local` etc), I would say this is a bug in creating the original buffer
variable with empty scope. If we want to allow such usage while keeping the two
scope consistent, we need to update the scope in buffer variable (which is not
simple). Right now we don't have such usage in the code base, so I chose to
drop `scope` argument from the `Buffer` constructor` to prevent misuse.
One possible middle ground is to keep `scope` member of `Buffer`, but drop
it from the constructor and instead initialize it with the scope in the buffer
variable (`data` in the code). This might be better in terms of design, in that
we also have `dtype` duplicated.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
