tvm-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wei Chen <>
Subject Re: [dmlc/tvm] [RFC] Register Relay VM design (#2915)
Date Mon, 01 Apr 2019 06:05:06 GMT
I explored @icemelon9 's register vm design in my branch:
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](
+ [linear scan]( 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:
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message