Ah sorry.. I read that not as either or list :slight_smile:
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-optionally-include-object-file-generation-in-tvmc/8120/5)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
Hi @aca88,
The object file produced by `tvmc` does not necessarily include the C runtime.
Using a `--bare-metal` flag just refers to the fact that it is mostly useful on
a bare-metal target.
Anyway, to avoid confusion, I think maybe `--object-file` might be a better
choice :slight_smile:
Hi,
Does `--bare-metal` imply that the C runtime has also been compiled and is part
of the `.o`?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-optionally-include-object-file-generation-in-tvmc/8120/3)
to respond.
You are receiving this because you enabled mailing list mode.
To
cc: @leandron, @ramana-arm
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-optionally-include-object-file-generation-in-tvmc/8120/2)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.apache
## Motivation
Currently `tvmc` will only produce a dynamic library version of the network,
i.e., an `.so` file stored alongside the other artifacts. This library is
usually dynamically linked to other applications.
With this change we want to add a flag to `tvmc` to get an object file (i.e.,
Glad to see a proposal which such functionality.
I have to admit that I had also done something similar to what you are
proposing (at least at the TE level).
One problem I had was enlargment of the tensor iteration domains
(https://discuss.tvm.apache.org/t/tvm-scheduling-split-factors-missma
Thanks everyone, the lazy consensus has passed.
--
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/6623#issuecomment-705716550
Thanks for the feedback :) Tiling the output computations + `compute_at` is
actually exactly what I've been doing to prototype this - and you're right that
for a sufficiently large tile the recompute isn't particularly bad. I think the
rolling buffers aren't immediately essential, but they wou
ahh, thanks for reminding. This is closed by #6337
--
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/4178#issuecomment-705664905
Closed #4178.
--
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/4178#event-3856212990
Closed #4332.
--
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/4332#event-3856174887
@zhiics @wweic would be great to get a status update and see if this PR can be
updated or closed
--
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/4178#issuecomment-705659481
Thanks @matt-arm This is certainly quite interesting for the case of fused
depthwise and 3x3 conv2d.
As a middle ground, perhaps it is worth while to think about simply tiling the
output computations and use the `compute_at` at the intermediate tiles, it
would of course less ideal than a rol
We at Arm would like to introduce a new optimization technique to TVM which we
refer to as 'cascading', which aims to optimize a network's peak memory usage.
While in many of the systems TVM targets today there is plentiful memory
available, for the embedded devices that uTVM aims to target, w
14 matches
Mail list logo
