Merged #71 into main.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/71#event-7112016296
You are receiving this because you are subscribed to this thread.
Message ID:
@Mousius want to make the other suggested updates? then I'm good with this RFC
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/71#issuecomment-1193570733
You are receiving this because you are subscribed to this thread.
Message ID:
> @kparzysz-quic, sorry, I'm still not understanding here - the name of the
> kind is enough to look it up in the kind registry and gather any
> kind-specific information. What further details are missing?
I thought the attrs were stored in the kind, but they are in the target itself.
Nevermin
@kparzysz-quic, sorry, I'm still not understanding here - the name of the kind
is enough to look it up in the kind registry and gather any kind-specific
information. What further details are missing?
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/
```C++
Map TargetNode::Export() const {
Map result = {
{"kind", this->kind->name},<
{"tag", this->tag},
{"keys", this->keys},
};
if (this->host.defined()) {
result.Set("host", this->GetHost().value_or(Target())->Export());
}
for (c
> Actually, the target JSON only shows the name of the kind, so the target
> parser (if it operates on the JSON) won't see the details of the kind, unless
> they are included in the JSON. I think that expanding the contents of the
> target JSON to contain the kind specifics as well is critical f
Actually, the target JSON only shows the name of the kind, so the target parser
(if it operates on the JSON) won't see the details of the kind, unless they are
included in the JSON. I think that expanding the contents of the target JSON
to contain the kind specifics as well is critical for this
@kparzysz-quic @junrushao1994 @tqchen @Lunderberg can you look at this one
again?
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/71#issuecomment-1184767286
You are receiving this because you are subscribed to this thread.
Message ID:
@areusch I replied to your comments, could you take a look and see if it makes
more sense to you? Then if we're all happy I'll do a final update on the text 😸
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/71#issuecomment-1167403744
You are receivi
In the spirit of keeping this simple to review, the text of this RFC has been
reformulated to cover the `target_parser` replacement for `preprocessor` which
@junrushao1994 proposed - I've raised a follow on for the `features` additional
to the `Target` so that can also be reviewed in isolation w
great! so I think we just need some updates to the text of the RFC based on
discusison, then we are good to merge.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/71#issuecomment-1134999125
You are receiving this because you are subscribed to this th
@Mousius Thank you so much for your response! This makes lots of sense to me!
Also, thanks for including my personal principles in the discussion! It's my
personal principles which are completely okay to disagree with :-)
> I'm not sure why we consider that pollution given it should have a posit
Thanks folks for discussions. I think they summarizes to the following points
- Q0: Subfield grouping (e.g. features) or simply leave as top-level attrs
- Q1: Folder structure: `target/preprocessors/cuda.cc` vs
`target/cuda/cuda_preprocessor.cc`
- Note that code-reuse is less likely going to
Thanks folks for discussions. I think they summarizes to the following points
- Q0: Subfield grouping (e.g. features) or simply leave as top-level attrs
- Q1: Folder structure: `target/preprocessors/cuda.cc` vs
`target/cuda/cuda_preprocessor.cc`
- Note that code-reuse is less likely going to
Hi @junrushao1994, thanks for the elaborate reply 😸 I don't want to debate our
personal principles but I appreciate you sharing them and will reference them
where I can.
> **Current `arch`-specifc checks.** Most of the 6 groups of `arch`-specific
> helper functions, mentioned in the "Motivatio
Thanks @Mousius for drafing this RFC!
First of all, I completely agree on the importance to handle `arch`-specific
checks. Use our experience as an example, on CUDA we might want to check if the
PTX intrinsic `cp.async.commit_group` is available on certain architecture
before tensorizing using
> 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
> 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
> 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
i'm supportive of this idea. i didn't want to derail this RFC by discussing
@kparzysz-quic 's idea about the architecture of the llvm target here, but i
think that would be a good follow-up discussion.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull
> 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 posterity.
> This would also help us to make meaningful choices that aligns wi
I think it's a good idea overall. I'm in favor of adding more internal
flexibility to targets.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/71#issuecomment-1125416129
You are receiving this because you are subscribed to this thread.
Message ID:
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
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
24 matches
Mail list logo
