cc : @masahi @Lunderberg
---
[Visit
Topic](https://discuss.tvm.apache.org/t/commit-message-guideline/12334/12) to
respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.apache.org/email/unsubscribe/3b0038
Thanks @gromero for taking this initiative.
I would actually push us to take a pragmatic route to enforce these (kind of
agreeing @driazati ) given the distributed nature of the TVM/OSS project,
failing that we fallback to being at least a "guideline" -- which we dont have
at the minute :) .
@driazati @leandron ,
I think this proposal will benefit all the work that require updates to
dependencies.
@masahi @Leo-arm @elenkalda-arm
I would suggest lets scope scripts that is relevant to this proposal (as it
seems there are already other places the attackers could exploit anyway) .
@kparzysz .
As mentioned in the PR, the above reference is about scalar constants, that is
not subject to link-params. (Correct me if I am wrong -- @dmitriy-arm ).
#8509 is about non-scalar constants.
One option is to hexagon backend needs to be adjusted to handle AllocateConst
nodes, instea
Hi @kparzysz ,
Sorry to hear that there was downstream failure because of #8509.
[quote="kparzysz, post:1, topic:12165"]
Float16 constants are not supported by constants in TIR and compilation aborts.
[/quote]
[quote="kparzysz, post:1, topic:12165"]
Constants that are not parameters cannot hav
I see. All good then :D
---
[Visit Topic](https://discuss.tvm.apache.org/t/rfc-remove-codeowners/12095/11)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.apache.org/email/unsubscribe/e723fbd60a6
@driazati @areusch ,
This looks like a great suggestion!.
I think the proposal is about adding a mechanism to use the cc tag to attach
people as reviewers, which seems good step.
I agree with @comaniac by helping the new authors finding people to tag for
reviews rather than doing a mandator
Hi @MJKlaiber ,
Apologies to for not getting back to this in time.
Thanks for the proposal! and it broadly looks like wrapping the Target Hooks
RFC (by @Mousius ) :
https://github.com/apache/tvm-rfcs/blob/main/rfcs/0010-target-registered-compiler-flow-customisation.md,
and exposing a nice/str
Hi @driazati ,
I would support this.
This is a great improvement as this would always verify the patches in the
environment where they are meant to be verified -- without having to merge
docker changes first and then running docker-staging job with the other changes.
@Mousius what do you thi
Thanks for the interesting discussion.
@tqchen @junrushao1994 ,
In terms of the definition of the target, I see two categories of arguments
presented here :
C1 : The executor, runtime, should belong to the target -- even if means
duplication.
C2 : The targets should be hierarchical and re
Hi @tqchen and @zxybach,
cc : @mbaret
What is a Composite Target ?
TVM being a multi-target compiler, it would be a bit confusing to use a Array
of Targets as another Composite Target -- I think its the terminology what is
confusing here.
A composite target sounds like a target that codegen
@masahi
There is another option you could take here.
The wildcard() actually works here because the constant remains in @main
function of the IRModule.
In the partition_for_* function where the full IRModule is visible (along with
@main and external functions) you could actually mutate the c
# Background
Currently, given a ML model primarily TVM will generate two main artifacts :
* A1 : Description of the sequential execution of operators :
1. If the "executor" is "graph", this would be a JSON
2. if the "executor" is "aot", this would be a main function describing call
graph o
Hi @tqchen,
Im not sure whether that requires different namespaces for the packages.
Why cant we use something as follows :
* Released versions: e.g.: tlcpack-0.8 tlcpack-0.8.1 tlcpack-0.9
* Pre-release versions instead of tlcpack_nightly:
tlcpack-0.10.devXXX
---
[Visit
Topic](https://
Hi @areusch @tqchen @giuseros
I think its best to use _tvm prefix nonetheless. -- so we dont pollute a
namespace based on a user given variable.
I dont follow why a "prefix" necessarily mean user being able to select it? If
"prefix" is not the right term we should not call it a prefix. The g
[quote="areusch, post:4, topic:9643"]
The main question I have though is: if we are just going to hoist tensors out
of operator implementations, why do we need to have a way to lookup PrimFunc
workspace size? Can’t we just get that by looking at the arguments?
[/quote]
We think they will get h
Yes, this part had been a pain point in figuring out which part of the
compilation pipeline is being run.
Regarding, the *lower*, I think C++ version is not run (maybe not anywhere in
the tvm compilation -- correct me if I am wrong) at the minute because there is
a check for the registered p
On a side note to this conversation about new primitives, would the new
TensorIR will include primitive "store_at" -- the one present in
Halide/Tiramisu ? -- I just want to know if thats something in the roadmap
:slight_smile: .
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-tens
So generally BYOC caters to two types of use cases that are mostly to handle
accelerators and optimized operator libraries (e.g., Arm Compute Library,
DNNL). I think in the world of micro, both of these should be invoked in the
target_host via Driver/Runtime API component. i.e., even though th
Hi @areusch ,
Thanks for taking time to put this all up. Overall it makes sense to me.
>
> (TODO, but not as a result of this RFC) Group the non-host modules by
> target_type (except that ext_dev target_types should be expanded to a unique
> key per BYOC). Save each generated module into a fi
Hi @gromero and @areusch ,
Interesting discussions!
> The only thing I see specific to that use-case is that it has an runtime
> “adapter” for TVM C and C++ interfaces (in bundle.c and bundle.cc) that will
> be used by the application and will be linked by an ad hoc (per project or
> applica
That is a good suggestion! @tqchen and it presents a good compromise for us to
see the complexities and opportunities that would open up by being able to
express the multi-op TIR blocks (hierarchical TIR blocks ?).
---
[Visit Topic](https://discuss.tvm.apache.org/t/rfc-cascade-scheduling/8
@tqchen, So this makes me wonder -- what are the exact reasons that we need to
maintain the relay abstraction until upto the graph runtime ? As @matt-arm
mentions, I quite like the idea of making fuse-ops a TIR (the improved one with
blocks) pass because currently its forward guessing the sema
Yes definitely useful to have! might save a lot of hacks/workarounds that would
otherwise needed to get the same functionality. Also cc : @spectrometerHBH
@merrymercy
---
[Visit Topic](https://discuss.tvm.apache.org/t/creating-store-at-in-tvm/8083/2)
to respond.
You are receiving this be
Yes, the ambiguity is something I was struggling with too, when having a
conversation. May I ask what does the "T" of old TIR stands for ? TVM ?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-tensorir-a-schedulable-ir-for-tvm/7872/40)
to respond.
You are receiving this because y
Thanks for the clarification! I concur that such a primitive should be useful
and would allow more flexible compute movements.
Regarding the full graph, I agree that relay (along with optimization) being
very useful. I was thinking whether there would be a benefit of lowering the
full graph t
Thanks for the proposal! Looks quite interesting!
Out of curiosity,
1) The concat example you've shown where the original stage is represented in
three blocks that seems to be assigning to the same buffer. I'm curious to know
what if we want to move the concat (using compute_at, if possible
27 matches
Mail list logo
