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)
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
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
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
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
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://
**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
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
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
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
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
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.
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
[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
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
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
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
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
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
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
20 matches
Mail list logo
