I explored @icemelon9 's register vm design in my branch: 
https://github.com/wweic/tvm/commits/relay-rts. Would like to share some data 
points.

We need to add special registers in VM for function arguments and return value. 
Return register is necessary because when callee function returns, its register 
file has gone. So return value must be persisted outside of register file. 

Opcode generation in register VM is easier, compiler doesn't need to maintain 
stack offsets all along, just memorize variable to register mapping. Then we 
need register allocation, I tried [liveness 
analysis](https://www.cs.cmu.edu/~janh/courses/411/16/lec/04-liveness.pdf) + 
[linear scan](http://web.cs.ucla.edu/~palsberg/course/cs132/linearscan.pdf). 
It's pretty straightforward since opcode is relatively simple. I'm not sure I 
understand @tqchen 's concern about handing control flow in register 
allocation.  Note that Haichen's register VM uses local register file per 
function. So we are doing register allocation per function, which shouldn't 
need to worry about interprocedural register allocations. As for branches 
inside a function, `live interval` of register can be the range from the 
earliest opcode to the last opcode that the register is live. I think linear 
scan would work fine under this setting.

In register VM we need to allocate a register file(`vector<Object>`) per call, 
equal to growing the stack in stack VM. I'm not sure if there will be much 
performance difference. 

Overall register VM is slightly easier to work with, debugging is painless. But 
I'm not sure if this is convincing enough to favor register VM. 

The major selling point of register VM is easy to discover dataflow. But it 
begs the questions that is register VM better at leveraging the dataflow 
information? I think it requires more thought. Fundamentally both VMs have call 
stack and will have similar problems when integrating with async execution 
engines.


-- 
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/2915#issuecomment-478447258

Reply via email to