> I think this is generally ok. I suggest elaborating a bit more in the text of
> the RFC that the preprocessors apply to the target kind, and that for all
> architectures, the code specific to each architecture would need to be
> handled as a part of the common preprocessor. The use of names li
> Thanks folks for discussions. Just want to chime in here. I think we all
> agree that the development and upstreaming flow should closely follow the
> normal process, which is A2 as being listed by @denise-k .
> To put it in another way, that the roadmap is independent from what/how
> things a
Thanks @Mousius, I'm aligned with the above and I've made a couple of quick
updates to try and address your comments. Please note that I'm out of the
office this week, so my responses may be delayed. I have asked Yuchen to
shepherd this PR while I'm out.
--
Reply to this email directly or view
> I like it overall, though I do have one potential concern: By making it
> easier to query the architecture compared to cross-architecture features,
> will developers more often use architecture-specific checks that
> unnecessarily limit TVM features to specific architectures?
Unfortunately, t
> Based on my previous re-review of LLVM, thanks to @tqchen, it might help to
> use my_target.features.dsp rather than my_target.arch.has_dsp and clarifying
> these are features available to the Target? What do you think?
I like that, and the renaming makes it clear which are boolean parameters
@ArmageddonKnight we might present/demo DietCode and introduce this RFC in a
community meeting. Maybe in 5/25 or 6/1?
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/72#issuecomment-1130262561
You are receiving this because you are subscribed to this
@areusch @comaniac Sure. I would be happy to. I will be traveling on 6/1 so
5/25 looks good.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/72#issuecomment-1130348204
You are receiving this because you are subscribed to this thread.
Message ID:
ok for A1 i'm good with named phases and we can modify as necessary. i think
the A2.2 solution of directly registering target attrs makes sense to me. is
that the direction we're aligned on here?
we can discuss this next week at the community meeting, or if we're in
alignment on these two items
Apologies for not following the conversation in detail in real time. Here are
some thoughts on how we can make sure an UMA-integrated accelerator is also a
Collage-supported 'backend'.
- The registration of patterns will need to support the existing triple of
(pattern name, pattern, predicate)
