tqchen commented on PR #15916:
URL: https://github.com/apache/tvm/pull/15916#issuecomment-1783840165
What we are discussing is closely related to our original consideration of
what forms a normal form and the general needs. Let me elaborate a bit more
The purpose of normal form is to restrict the set of possibilities in
representing the same program thus helping reduce the assumption that one might
take when writing pass. Of course it imposes extra demand for passes to ensure
things go back to the normal form(the wellform-ness check). Currently, the
relax normal form requires that we normalize all non-tuple nesting, but expand
all tuple constructions.
That means we encourage forms like
```python
def func(x, y):
lv0 = call_tir(mm, (x, y))
```
But do not encourage
```python
def func(x, y):
lv0 = (x, y)
lv1 = call_tir(mm, lv0)
```
The reason we do that is to observe a general category of need:
N0: Structural intrinsic argument
When constructing intrinsics, we would like intrinsics to present certain
structures in them, for example `call_tir`, `call_packed`. If we want to
analyze read write relations low-level, maybe we would like to have intrinsics
of
lv0 = call_func_with_read_write(func, read_tuple, write_tuple)
Pattern match and rewriting of these structural intrinsic is a first-class
need in our case because of following reasons:
R0: they are common needs in machine learning passes, i can easily write a
customized pass that matches and replaces the call_tir, such needs are also
unbounded.
R1: We would like to make that customization happen at a third party, aka
the developers who do not necessarily contribute to upstream can do it as
simply as possible without worrying about unpacking tuples.
Such a normal form might bring a bit of restrictions, but won’t be too much
to other possible passes that are “generic”. This also depends on the past
writing patterns we do. Let us consider the following patterns
PT0: Only overload visit call and unpack that during visits
PT1: Possibly overload visit tuple
I would claim that PT0 is actually more desirable and handles almost all the
pass needs, and it won’t cause any issues in the structural intrinsics, since
all arguments are transformed and pattern matched together.
I think most of the possible ideas of difficulty mentioned are related to
passes that follow PT1. Under the current normal form however, we naturally
need to be very careful about PT1, because we do not want to lift common values
in tuple construction and instead encourage tuples to be always unpacked, it is
harder to think about. A CSE pass that tries to detect sub-tuples and lift
common values via PT1 actually would violate the normal form requirement.
A rule of thumb under the current normal form is that we almost always won’t
do PT1, unless one passes that populate tuple annotation(aka deduction). If
there is another pass that does so, we should visit the assumption and check
carefully if the result can violate the normal form assumption. And if there
are passes that do tuple replacement, we can still insert an extra helper pass
that turns some of the indirect tuple reference into the unpacked form by
checking structural info and unpacking them.
Finally, one should note that the passes might touch PT1 are usually
developed in repo, as a result, the extra consideration of renormalization
won’t be hurt, as our experience is sufficient to tackle these considerations.
Burdens of R0/R1 are unbounded, a lot of our designs(e.g. Dataflow block) goes
into simplifying them for developers who may not have a deep background.
Of course all of the above roots back to our rationale of the normal form.
One can argue we should take other normal forms(e.g. Tuple value should always
be bound to a variable), in which case the consideration would be different and
there are other tradeoffs. We considered these tradeoffs before arriving at the
current one.
--
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]
