[quote="tqchen, post:2, topic:1721"]
MLIR as itself is a meta-way of defining IRs, in the folks’ word “XML for IRs”
... Concrete compiler solutions still need to be built for each layer of the
dialect languages, and they can be very different due to the difference in the
semantics of the opera
@jroesch There is no easy description for a backend. Currently these
meta-templates are mainly based on the summary of existing human schedule code
in TOPI. So adding a new backend is still hard. What can be reused is the
classification of compute type.
@kevinthesun There is only one template f
Good comments. I would like to separate the answer in two parts, and this is an
updated view after I take look at the MLIR's codebase.
## Interpretation of MLIR's Vision
I think what you answered reflects MLIR's vision. Make the abstract class of IR
and derive dialects. But not necessarily pr
No offense.
The difference between rust-sgx-sdk and Fortanix EDP roots from basic
assumptions of security. Fortanix EDP is not designed for security, so it has
assumptions of trusting the OS. For example, the atomicity of EDP's SGX
`RwLock` is **untrusted**. Technically, Fortanix EDP maintains
Hey @dingelish cool to see you here! Thanks a lot for the input. One point of
note for the TVM use-case is that the [TVM modules' thread pool already
requires cooperation from the
OS](https://github.com/dmlc/tvm/blob/master/rust/runtime/src/threading.rs#L132).
In almost all (or maybe actually a
Yeah I 100% trust you :)
Correct me if I'm wrong:
[`SGX_QUEUE`](https://github.com/dmlc/tvm/blob/7cd986db0e67583bc347ed208c25be4c0d0c32a0/rust/runtime/src/threading.rs#L198)
relies on the implementation of `Mutex` inside SGX. In Fortanix's solution,
it's relies on
[`WaitQueue`](https://github.
Well, if it's any consolation, the [rustc sgx thread implementation does the
exact same
thing](https://github.com/rust-lang/rust/blob/master/src/libstd/sys/sgx/thread.rs#L64)
as we're already doing. Might as well reduce code duplication, right?
--
You are receiving this because you are subscri
The following error occurs when I try to compile an onnx model. From what I can
tell using [Netron](https://lutzroeder.github.io/netron/), there is an input
`W`. However, it's not another node but instead some (static) initialization
data for the current node.
The model can be downloaded here
The current code of SGX_QUEUE (with rust-sgx-sdk) is not depending on untrusted
Mutex -- it relies on sgx_spin to provide atomicity which keeps everything
inside.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://gith
The code you referred to is exactly Fortanix's code. The JoinHandle is
implemented using untrusted Mutex. I don't think their implementation could
provide any trustworthiness. They bring too much uncertainty to the SGX
environment. Personally, I strongly disagree with their implementation becaus
Any thoughts on the best way to do this?
I gave it a shot here:
https://gist.github.com/bwasti/a9d3b82d06f0de7df34a04e0c1ae4764
but didn't make much headway -- I hit a hard to decipher error in the Bind
logic:
```
RuntimeError: [23:10:17]
/home/bwasti/local/pytorch_tvm/tvm/src/runtime/module
11 matches
Mail list logo
