Grant Report - MoarVM JIT Compiler Expression Backend - May 2019
Fri, 07-Jun-2019 by
Mark A Jensen
edit post
<![CDATA[
Bart reports the latest progress:
> - Fixed a few windows-specific bugs (the ABI that we have to compile to is different between Windows and POSIX)
> - Assigned a permissible-register set to live ranges, which makes it possible to combine values with distinct register requirements (relevant for generalized register requirements)
> - Ensured that when a value is spilled to make place for another, the released register is actually one that the new value can use.
>
> In other words, a bunch of register allocator work. Floating point support is close to being finished.
He adds that he plans to render the expression Intermediate Representation tree in a linear format:
> Aside from that, I've been planning my next move - which I intend to be a refactor to transform the 'expression' IR tree into a linear format. This has the following advantages:
>
> - The (relative) order of instructions in code is reified - that makes it possible to write a transform that changes this order.
> - And it also makes it possible to assert that we don't write an invalid order (this was the problem I reported on a few months back)
> - It becomes easier to write fragments that span multiple basic blocks. This should improve code generation (can keep values live longer).
> - The 'linearizing' conversion can be done in Perl, which is altogether easier to work with.
>
> Most parts of the existing JIT are, fortunately, barely affected by
> this change. The main advantage of the current structure is that it is
> fairly trivial to manipulate. I'm still investigating how best to
> implement the linear IR so that manipulation remains easy and cheap.
> (Unfortunately, using a pointer-and-structure based system is fairly
> expensive because a single MoarVM opcode expands to a multitude of
> expression operators).
MAJ
]]>
Comments (0)
