> Is there any technical reason blocking us from extending DLDataType to have a
> `is_scalable` vector field, allowing us to maintain the meaning of the lanes
> field to represent the number of lanes?
DLDataType comes from dlpack not TVM. Changing it may affect the ABI of any
function acceptin
I guess we could pass an argument to the vectorizer whether to generate
SVE-friendly code. If this is limited to emitting additional TIR builtins,
then I'm ok with that. I just want to be able to reuse as much of the
vectorization code as possible between SVE and non-SVE targets.
As far as pr
> Could it instead be in a target-dependent lowering pass?
Sure. My idea is to have a single SVE-aware vectorization pass in TVM, and
then be able to utilize it for all targets. I'm particularly interested in
predication. How the codegen is done doesn't matter much.
--
Reply to this email d
Sorry for the delay... What I'm aiming at is to be able to lower the TIR to a
generic CPU, that is to an architecture that does not support SVE. The TIR
will need to have some default lowering in CodeGenLLVM/CodeGenCPU, so being
able to do that is important. For that, we should be able to ass
Thanks for bringing this up again.
A few suggestions to make it more general:
1. Add a parameter to `tir.vscale` to state the minimal assumed vector length.
For AArch64 SVE it will be 128 (bits), but some other non-SVE architecture can
provide a different value (via a target hook, or something
Say we have
```
for y, x in T.grid(10, 10):
with T.block("block"):
B[y, x] = A[y, x] + 1
```
Is there any advantage to adding axis remap if we have 1-1 correspondence with
existing variables?
```
for y, x in T.grid(10, 10):
with T.block("block"):
v_y, v_x = T.axis.remap(
Merged #13495 into main.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/pull/13495#event-7903034464
You are receiving this because you are subscribed to this thread.
Message ID:
0
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/12583#issuecomment-1231775741
You are receiving this because you are subscribed to this thread.
Message ID:
Should we still wait for review from Junru?
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/83#issuecomment-1185759039
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
```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
If we add another member to `Target`, how will this interact with the [target
parser proposal](https://github.com/apache/tvm-rfcs/pull/71)?
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/78#issuecomment-1185653525
You are receiving this because you
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
I updated the text of the RFC, the rendered link above, and the [prototype
draft PR](https://github.com/apache/tvm/pull/11933).
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/83#issuecomment-1183772746
You are receiving this because you are subscrib
It does, yes:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Bitcode/Reader/BitcodeReader.cpp#L91-L99
The flags above come from the latest development branch, so in order to handle
all LLVM versions we'd need to check all of them since 4.0 (which I'm ok
doing), and we will need to keep
> > The reason is that ParseIR needs to make calls to LLVM functions to create
> > the llvm::Module.
>
> I get this part, my main question is whether we can initializeLLVM in the
> Target constructor but do option resetting in enter/exit, i could miss
> something here.
I see what you mean. My
> Just to followup, why does ParseIR require activation of a scope, or is it
> possible that ParseIR returns a tuple of Target and Module, where activation
> is done separately.
The reason is that `ParseIR` needs to make calls to LLVM functions to create
the `llvm::Module`.
--
Reply to this
To address the second question: we shouldn't allow nesting of LLVM scopes. The
reason is that if the target doesn't specify any command line flags, the
assumption is that it will rely on LLVM's defaults. If we were to nest scopes,
and the outer scope did modify flags, then the inner scope (wit
Both `LoadIR` or `ParseIR` take an optional pre-existing `LLVMContext`, and
return a pair `{llvm::Module, LLVMScope}`, where the scope object in the pair
is newly constructed, and contains the given `LLVMContext` (or create a new one
if none was given). In the first call to `ParseIR`, the calle
@tqchen @junrushao1994 Do you have any additional comments?
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/83#issuecomment-1176373905
You are receiving this because you are subscribed to this thread.
Message ID:
> my one question, which i think is mainly open-ended now, is how we handle
> LLVM arch that have unique flags that, right now, would show up in TVM as
> target-specific llvm flags.
I'd have to see a practical example of that to get an idea of what's expected.
For Hexagon we'd want to automati
> Hi~ here are my two questions :) cc @kparzysz-quic
> What is the different between
>
> * `sch[C].vectorize(v, vector_length=32)` and
> * `vo, vi = sch[C].split(v, 32)` then `sch[C].vectorize(vi)`
>
> It seems that we could also choose to properly lower the sp
To reiterate---my original concern was that the first RFC was proposing changes
to target-independent part of TVM to add support for a very target-specific
feature. However, I do think that we can move this forward in way that would
be overall useful.
Here is the outline of my thoughts on this
`IRModule` already has functions to create new globals. With the
name-generating `NameSupply` added to the module, these functions could use
that implicitly.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/84#issuecomment-1172379948
You are receivi
A couple of thoughts...
- We should have a common facility that represents a scope in which names need
to be unique. Conceptually it could be a set of "known" strings (that are
presumed used), and something (like a private counter) to generate a unique
suffix. The use would be `new_name = Gen
[Rendered](https://github.com/apache/tvm-rfcs/blob/aba8fa123cd0de1e3a8d752f0b55741aa674a1b0/rfcs/0080-llvm-target.md)
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/83#issuecomment-1167976257
You are receiving this because you are subscribed to this
You can view, comment on, or merge this pull request online at:
https://github.com/apache/tvm-rfcs/pull/83
-- Commit Summary --
* [RFC] Encapsulate LLVM target for use with LLVM libraries
-- File Changes --
A rfcs/0080-llvm-target.md (174)
-- Patch Links --
https://github.com/apache
It is supported in the sense that you should be able to compile and execute any
model. There is still a lot of work we need to do to make it perform well.
Right now we're working on many infrastructural changes in TVM, and the actual
code generated for Hexagon is still far from optimal.
I'm working on a prototype now. I want to iron out any additional issues
before we go on to discuss more details.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/modularizing-llvm-codegen-jit/12764/38)
to respond.
You are receiving this because you enabled mailing list mode.
To unsu
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:
Try `mods.get_function(...)` instead.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/attributeerror-module-object-has-no-attribute-getfunction/12337/2)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://di
It's been deprecated a long time ago. Is it still maintained? If not, I
suggest that we delete it.
---
[Visit Topic](https://discuss.tvm.apache.org/t/should-we-delete-nnvm/12330/1)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these email
I'm not particularly unhappy with the current situation, but it could be
improved.
+1
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/10471#issuecomment-1058659652
You are receiving this because you are subscribed to this thread.
Message ID:
I think this is a good idea. In my opinion it would be authors' responsibility
not to abuse the new ability: the merge directive should be added only once the
PR has reached an agreement. That is a subjective judgment, but it would be
hard to codify it.
One question---what should happen if
Sure, I replied in the [PR](https://github.com/apache/tvm/pull/8509).
---
[Visit
Topic](https://discuss.tvm.apache.org/t/problem-with-fuseops-and-embedded-constants-in-tir/12165/8)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails,
We were hitting this assertion:
https://github.com/apache/tvm/blob/main/src/relay/backend/te_compiler_cache.cc#L242
We do have a unit testcase that checks the LLVM IR to see if the _linked_param
function was generated, but I'm not sure if it runs in CI right now, since it
requires Hexagon targ
Long story short, after https://github.com/apache/tvm/pull/8509 we see a lot of
floating point models crash during compilation for Hexagon. On Hexagon
(downstream) we use the mixed-precision pass to convert float32 data to
float16. Float16 constants are not supported by constants in TIR and
There are 3 security vulnerabilities in Pillow < 9.0.0. They are all
considered critical.
1. [CVE-2022-22815](https://nvd.nist.gov/vuln/detail/CVE-2022-22815)
2. [CVE-2022-22816](https://nvd.nist.gov/vuln/detail/CVE-2022-22816)
3. [CVE-2022-22817](https://nvd.nist.gov/vuln/detail/CVE-2022-2281
Right, but users of DLPack will not see `DataType`, only `DLDataType`, unless
they use TVM as well. Changing `DataType` will only affect those that use
`include/tvm/runtime/data_type.h` (i.e. the ABI breakage will be limited to
users of TVM).
--
You are receiving this because you are subscrib
> DataType and DLDataType are part of DLPack standard,
The `DataType` type is defined in TVM, it's not present in DLPack. Or am I
missing something?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache
How will vectorization work? If there is a `vectorize` directive spanning a
logical extent, will the vectorization pass create multidimensional `ramp`s?
How will vector loads and stores be represented?
--
You are receiving this because you are subscribed to this thread.
Reply to this email di
Hexagon support still needs more work.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/8976#issuecomment-919449057
+1
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/8928#issuecomment-916143196
Currently a `PrefetchNode` is replaced with a loop nest doing single cache line
prefetches, and that's done in the storage flattener. This is bad for Hexagon,
because Hexagon has a prefetch engine which can prefetch a 2D buffer in the
background, but it requires a different setup. Once the l
The goal is to rewrite the TIR into a way that the target's codegen can handle.
Rewriting `exp` into `llvm.exp` can be seen as legalization too. There can be
targets that can generate code directly for `exp`. In fact, the translation
from `exp` to `llvm.exp` is only there for convenience (au
Why would an op have both? This is still the question that hasn't been
answered. What was the intent behind having "lowering" and "legalization" as
different things?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/is-there-a-difference-between-lower-and-legalize-in-tir/10714/8)
to r
We should have a way of legalizing builtins/intrinsics that can involve
creating new statements. Not every builtin may be replaceable with an
expression. Has anybody thought about doing that?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/new-target-intrinsic-lowering-and-legalizati
>From what I've seen so far there is no difference at all, conceptual or not.
>We should stick to one and get rid of the other. Both operate on the same TIR
>representation. In one case the TIR expression is replaced by another
>function call, in the other the resulting expression is more c
Intrinsics and ops are represented in the same way in TIR though. What is the
intended behavior of "legalization" that is different from "lowering"?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/is-there-a-difference-between-lower-and-legalize-in-tir/10714/3)
to respond.
You are re
Just found this thread. [What's the intended difference between lowering and
legalization?](https://discuss.tvm.apache.org/t/is-there-a-difference-between-lower-and-legalize-in-tir/10714/2)
---
[Visit
Topic](https://discuss.tvm.apache.org/t/new-target-intrinsic-lowering-and-legalization-m
Both, `FLowerIntrinsic` and `FLegalize` are the same type, and they are handled
in a pretty much the same way. Is one of them being phased out?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/is-there-a-difference-between-lower-and-legalize-in-tir/10714/1)
to respond.
You are receivi
There is a benefit of having the association between a `Var` and the
corresponding `Buffer` throughout the optimizations, including codegen.
`Buffer` is not a `PrimExpr`, so it cannot be passed around directly, but it
contains a lot of useful information (such as shape etc.). If we had the
[quote="giuseros, post:29, topic:9206"]
>From what I understand @kparzysz you are saying that the internal functions
>don’t matter (they will be static private functions) but that the runner
>function should have this signature. Can I ask you why?
[/quote]
The reason is that this is the signat
Freshly rebased PR, that has nothing to do with docs:
https://ci.tlcpack.ai/blue/organizations/jenkins/tvm/detail/PR-6738/2/pipeline/321
Please fix this.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/ci-is-still-failing-in-docs/8266/1) to
respond.
You are receiving this because you
We are catching up on upstream development in our local repo, and we ran into
an issue: pointer annotation on buffer variables blocks buffer type casting.
See https://discuss.tvm.apache.org/t/type-casting-a-buffer/4035 for more
details. In short, given a buffer of one data type, we want to
If it's only available as a topi operator then you couldn't use it in a
`compute`. This is a scalar function, an arithmetic operation of a certain
kind. We have plenty of math intrinsics in TIR already, so this isn't a
precedent. You can have a topi operator for it, but it should be usable
I'm in favor of the intrinsic. Pattern matching of code (idiom recognition) is
generally a pain.
If we go that route, we should define it in such a way that the two values to
multiply are interchangeable, i.e. `fpm(x, y, s)` is same as `fpm(y, x, s)`,
i.e. the `x` and `y` are values to multi
What relay expands to is memory copy. I want to avoid that. I want to have a
copy-less representation in TIR.
This should really be a no-op, but ends up copying everything.
```
import tensorflow as tf
import tvm
import tvm.relay
g = tf.Graph()
with g.as_default():
u = tf.unstack(tf.placeh
Is there any effort to support tensor arrays in TIR? That would be something
to represent operations like `stack` or `unstack` from TF.
Let's say we want to write an op that does a concatenation of a variable number
of tensors, but without actually copying any data. Instead, it would create
I guess that's ok. Let's see how it works and we can refine it later if needed.
---
[Visit Topic](https://discuss.tvm.ai/t/rfc-tvm-target-specification/6844/33) to
respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https
Going back to the `target_host` question. Another argument against is that a
specific device can be present in different systems with different host
processors. This would necessitate having different targets for the same
device, if `target_host` is a part of the target description.
I don't
[quote="tqchen, post:28, topic:6844"]
Another way to think about it is that llvm itself is a target, and we happened
to have a JIT engine locally for that target.
[/quote]
This is precisely the point of view that I strongly disagree with. The code
that runs is not LLVM IR, it must be compiled
The question is "what do we want the target to guarantee?". If we want "llvm"
to include both CPU and JIT, then it should always mean that both features are
present. Whether the target is local or not is a feature of the runtime
environment and not the compiler. On that note, I think we sho
Another thought is that we should **remove "llvm" as a target**. Right now
target = "llvm" means "cpu", but it also means "jit". We should replace it
with something that has a clear meaning, and should be independent of whether
the LLVM framework is used to generate code for it or not.
In such case we can have
```
GPU_target = [ id: "cuda" ]// non-composite, no target_host
System_target = [ id: "cuda", id: "cpu" ] // composite
optimize(E1, GPU_target) // func, target
set> S = legalize(E1, System_target)
for s in S:
low_level_optimize(s.first
If it's possible that the entire E1 can be compiled for a single device then it
makes sense to treat it as device code. In such case, moving `alloc` to the
host could be treated as an "optimization" that is specific to this target.
However, if E1 has a non-composite target, how would that op
I'm not opposed to composite targets, I'm arguing that the way we handle
composite targets should not depend on what targets are members of the
composite target. Whether it's "CPU+GPU" or "CPU+GPU+DSP", the logic of the
analysis should be the same. The decisions it makes can be different,
o
V0 is not really well defined. Consider some hardware that has both a GPU, and
a DSP (as well as some host CPU). If you write a program for this system, is
it a GPU program, or a DSP program? What target will TOPI assume for the
operators in this program?
When you consider an example for
**Scope of a Target**: Why do linker options belong to runtime configuration?
Linking is a step in the module creation process, and it does affect the
contents of the module. Are there any implicit assumption made about modules?
**Composite Target**: From the point of view of modularity, hav
Would clang-format replace cpplint, or would we have both?
---
[Visit
Topic](https://discuss.tvm.ai/t/ci-lint-enabling-clang-format-based-lint-checks/6170/9)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://
I'm a bit late to this, but here are my thoughts:
The hardware string shouldn't be the only way to define target, it should be a
convenient shortcut of a more complex definition. I think that's what **S0**
does---we can maintain a mapping from a set of predefined hardware "keywords"
into an
Is it going to be compatible with `std::optional` from C++17? It would be nice
to just switch to the `std` version, once we start using C++17.
---
[Visit
Topic](https://discuss.tvm.ai/t/allow-non-nullable-object-and-introduce-optional-t/6337/7)
to respond.
You are receiving this because
A number of PRs fail in the same place (Unit Tests, python:i386), seemingly
unrelated to the PR itself. This is blocking these PRs. Is someone
investigating this?
The end of the failing log:
```
In file included from runtime.c:65:0:
../../src/runtime/crt/ndarray.c: In function 'TVMNDArray_Lo
We're back.
https://github.com/apache/incubator-tvm/pull/5252
---
[Visit Topic](https://discuss.tvm.ai/t/introducing-hexagon-backend/2421/31) to
respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.ai/e
+1
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-tvm/issues/5102#issuecomment-601388834
What is the planned release date for 0.6?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/dmlc/tvm/issues/2623#issuecomment-512574087
The special runtimes are mostly for offloading to extra devices from host. ARM
and X86 are usually the hosts, so the runtime for them is fairly simple. It's
still there, look at cpu_device_api.cc for example.
---
[Visit Topic](https://discuss.tvm.ai/t/introducing-hexagon-backend/2421/18)
77 matches
Mail list logo
