You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tvm.apache.org by GitBox <gi...@apache.org> on 2021/11/18 05:01:32 UTC
[GitHub] [tvm] wrongtest edited a comment on pull request #9482: Implementation of Common Subexpression Elimination for TIR
wrongtest edited a comment on pull request #9482:
URL: https://github.com/apache/tvm/pull/9482#issuecomment-972538596
I have another three questions about the pass.
1. Since function calls are non-eligible, it seems to prevent many common non-stateful builtin computations from being optimized, such as `tir.floordiv`, `tir.shift_right`, `tir.likely`, `tir.log` and etc. TVM already have op annotation like `PURE`:
https://github.com/apache/tvm/blob/main/include/tvm/tir/op_attr_types.h#L60-L67
what if to add an annotation type like `DETERMINISTIC` to mark the function return same output on same input. It should be
safe to eliminate common calls if the call op is both pure and deterministic.
2. Is the let binding semantic in tir explicitly what we want? Is the value expr is specified to be evaluated at let scope entry? otherwise there may be no reuse effect if let-binding allow the value expr get lazily expanded in let body.
3. Is this possible for some complex (but common) expr to be lifted out of control flow scope? eg
```python
if cond0:
tir.evaluate(complex_e) # slow path
else:
if cond2:
tir.evaluate(complex_e) # slow path
else:
... # general fast path
```
after CSE maybe comes to
```python
x = tir.Var("int32")
with tir.let(x, complex_e): # always evaluate slow path
if cond0:
tir.evaluate(x)
else:
if cond2:
tir.evaluate(x)
else:
... # general fast path
```
--
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: commits-unsubscribe@tvm.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org