tqchen commented on PR #12084:
URL: https://github.com/apache/tvm/pull/12084#issuecomment-1183695888
Thanks @tkonolige. These examples are quite helpful, especially the larger
ones as they helped to reveal problems in earlier part of the pipeline. In this
case it was fixed by the other PR but it is a good protocol to follow, so in
case we didn't have the fix before, it helps to reveal the problem.
High level summary of approaches.
- S0: When we generate the program as a result of transformation, if somehow
the intermediate region is bad due to some analysis, we probably end up in a
wrong spot for good perf, as a result, a warning or simply say this is not
something that we antiticpate (during search) so skipping early and look at
another one could be useful.
- S1: There are cases where finding constant upper bound is useful, and can
be done in an intentional way, that might relates to cases where we indeed have
loop dep intermediate results(like in sparse case)
- S2: There are cases where dynamic size alloca can be intentional, one
possible case is where we have share memory allocation that dep on input
variables.
The particular example seems should be on S0(error out so we find the
problem in earlier part of the pipeline) category. In the meantime, I think it
is certianly valuable to introduce S1 in some settings.
The question is where should that happen, and how much symbolic analysis we
want to involve.
In this case leave the alloca as it is(and not lifting) might be OK, and
desirable when the variable bound is unknown, e.g. in the case where we have
the following case
```python
@T.prim_func
def func(out: T.Buffer[n, "int32"]):
for i, j in T.grid(16, 16):
buf = T.allocate([1024 * j * n ], "int32", "global")
```
To modularize the step a bit, perhaps we can have a separate pass that
performs the upperbound setting when it is possible.
--
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]
