Thanks for the reply, atleast I'm not the only one who is using the deleter_
hack to find the types of nodes.
And thanks for the ideas with PrettyPrint, I haven't used it too much in gdb, I
normally use the `p tvm::Dump(xxx)` for printing Objects and ObjectRefs.
So, out of curiosity, is ther
I use the same way, and when I need inspect more details of the class object, I
will use `p PrettyPrint(xxx).c_str()`, in addition if I want a more clear
display(do the real line break instead of just print it as "\n"), the gdb
command `call (size_t)puts(PrettyPrint(xxx).c_str())` will be used
hi @heatdh,
i believe the kernels are in `c_mod.imported_modules[0]`. can you try
`c_mod.imported_modules[0].save("lib.s")`?
andrew
---
[Visit
Topic](https://discuss.tvm.apache.org/t/llvm-backend-for-riscv-follow-up/10824/2)
to respond.
You are receiving this because you enabled mailin
Hi,
I think that I am having a similar behavior when trying to compile
[YOLOX-ONNX](https://github.com/Megvii-BaseDetection/YOLOX/tree/main/demo/ONNXRuntime)
models in TVM.
```
%40 = dyn.strided_slice(%0, %8, %9, meta[relay.Constant][7] /* ty=Tensor[(4),
int64] */,
begin=None, end=None, st
Following up with my forum post,
https://discuss.tvm.apache.org/t/using-llvm-target-for-riscv-incompatibility-error/10393?u=heatdh
I tried to implement the workaround that was suggested to solve the soft
floating issue , added to some other approaches.
Automatically by exporting the IR edi
in
[MetalWorkspace::CopyDataFromTo](https://github.com/apache/tvm/blob/main/src/runtime/metal/metal_device_api.mm#L228)
three situation is handled:
1. Copy from Metal to Metal
2. Copy from CPU to Metal
3. Copy from Metal to CPU
I.e. in your case one more extra copy will be done and it will be m
