Thanks @Mousius . Given these fields are pretty relevant to compiler
configurations in traditional domain, it would be nice to also discuss prior
approaches(e.g. where those fields normally sits in say LLVM) for reference
--
Reply to this email directly or view it on GitHub:
https://github.com
> I think the main outstanding thing is the question of support here. I'd love
> for a few more folks to weigh in, tagging a few folks who may have ideas:
> @tqchen @jroesch @kparzysz-quic @u99127 @Mousius @leandron @comaniac @zhiics
> @Hzfengsy @ZihengJiang @yzhliu @masahi @icemelon
>
> broadl
Yeah that index was down for a while last week
(https://github.com/apache/tvm/pull/11156#issuecomment-1112015086) but it
should be working now. If this happens again we might want to look into
rehosting some of those assets
--
Reply to this email directly or view it on GitHub:
https://github.c
@yangulei i think this means the CI's quota to PyPI was exceeded. perhaps retry
now that it's been a while?
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/pull/11140#issuecomment-1124197882
You are receiving this because you are subscribed to this thread.
Me
> @Mousius that's my suggestion. i don't know who should do it--perhaps at
> least the nominated person is responsible for finding someone to do it and
> ensuring it's done?
I'd suggest we make it clear it may be required when taking the role, but
equally if they find someone to swap with then
thanks for summarizing the meeting! I agree with @areusch's points on support
and have added some text about it
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/67#issuecomment-1124178464
You are receiving this because you are subscribed to this thre
@Mousius that's my suggestion. i don't know who should do it--perhaps at least
the nominated person is responsible for finding someone to do it and ensuring
it's done?
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/67#issuecomment-1124158305
You ar
for A1, what do people think of an ordering spec e.g.
```
self._register_relay_pass(ConfigGenerator(), before="FuseOps",
after=("MergeComposite", "abcOtherPass"))
```
my concern is that whether int or enum, people are really expressing a
dependency graph here and while we hope it is not terribly
sorry i'm behind on PRs, but I definitely support this effort!
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/68#issuecomment-1124148574
You are receiving this because you are subscribed to this thread.
Message ID:
> my vote is the following (for now, we can revisit at 1.0):
>
> * we agree we will fix major bugs on `0.X.Y` where `0.X.Y` is the latest
> release.
> * when we make a new minor version release e.g. `0.(X+1).0`, we will stop
> maintaining releases starting with `0.X.` at that time.
> * committer
@wrongtest Thanks for bringing up this. There are a few options for the
behavior in TVM script, I'm open to discussion.
* A1: The original behavior before https://github.com/apache/tvm/pull/9727:
`T.allocate` returns a `Var`, which can be later used in `T.load / T.store`.
* A2: Current behavior:
Merged #63 into main.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/63#event-6592569248
You are receiving this because you are subscribed to this thread.
Message ID:
I think the main outstanding thing is the question of support here. I'd love
for a few more folks to weigh in, tagging a few folks who may have ideas:
@tqchen @jroesch @kparzysz-quic @u99127 @Mousius @leandron @comaniac @zhiics
@Hzfengsy @ZihengJiang @yzhliu @masahi @icemelon
broadly, the ques
Thank you @manupa-arm for this input! I'll go over the points in more detail in
the next few days.
For A1,
I agree, that enums are generally a cleaner solution. We stuck with ints until
now because of the the following two reasons:
- Phases for TIR passes are currently also int-based
- For some
+1
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/68#issuecomment-1124005594
You are receiving this because you are subscribed to this thread.
Message ID:
We discussed this RFC briefly this morning at the [Community
Meeting](https://discuss.tvm.apache.org/t/next-tvm-community-meeting-may-11/12714/3).
Here are notes:
- @Mousius notes that because we're 0.x version numbers, we don't need to worry
too much about breaking APIs
- @driazati notes that m
For A1,
My personal preference is that we go for Enum based approach rather than int s.
Unless, of course, we have a good reason not to do that -- which I think should
be outlined in the RFC for future reference.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/t
In order to help to progress with A2,
I can think of two solutions :
A2.1 : We could register a sub_target string (similiar to a mtriple in LLVM)
and a decoder (e.g. :
_register_sub_target_decoder(ultra_trail_target_decoder(str)) -->
AttrDict/Dict. We could register the attr_dict as uma_attr
You can view, comment on, or merge this pull request online at:
https://github.com/apache/tvm-rfcs/pull/71
-- Commit Summary --
* Add Target Pre-processing RFC
-- File Changes --
A rfcs/0070-target-preprocessing.md (208)
-- Patch Links --
https://github.com/apache/tvm-rfcs/pull/71.p
Great work @grant-arm, a very positive initiative!
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/68#issuecomment-1123505773
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #68 into main.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/68#event-6588785727
You are receiving this because you are subscribed to this thread.
Message ID:
Thanks a lot! I think then we can handle buffer related issues in customized
passes with more explicit and robust way.
I have one question on tir script, for certain algorithms in DL workloads,
users may want to write non-stir formed script like
```python
x = T.allocate((), "int32", "")
x
22 matches
Mail list logo
