[Mono-dev] ir instructions.

Paolo Molaro lupus at ximian.com
Tue Feb 23 12:07:20 EST 2010

On 02/22/10 Rodrigo Kumpera wrote:
> On Sat, Feb 20, 2010 at 2:07 AM, Jerry Maine - KF5ADY <crashfourit at gmail.com
> > I remember you talking about instead of having marcos and defines
> > describe certain attributes of IR instructions, having them be defined
> > in a single data structure like what is done for when calling LLVM. What
> > would that entail?
> >
> That would entail been able to encode more properties and relations of
> instructions
> without all the repetition that currently exist in our JIT.

All the repetition can be trivially eliminated: nobody did that yet
because it's mostly a waste of time at this point (and some invariants
in opcode order need to be maintained right now, so changing things
blindly could break code).

> There are 3 different problems I think deserve been solved.
> The first is encoding of instruction properties such as commutative or
> side-effect free.
> For this it would be a matter of adding an extra parameter to the MINI_OP
> macro or'ing
> those properties and then filling a table with this data.

Right, so there is no need for the bloat of tablegen for this (not
counting the build issues it would bring on).

> The second is encode relations between instructions. For example,
> op_to_op_dest_membase
> is only enabled on x86/amd64 and to small amount of operations. Doing this
> for all SIMD ops
> would be a a lot of repetitive work.

See the attached program that will generate all the stuff you need there
and more. It can be trivially enhanced to generate also the backend
code or mono_op_to_op_imm() support.

> The last is to reduce the amount of repetition between instructions
> definitions, it has to be very
> template oriented and support customization of the result. For example, I
> want to define a single
> template for binary SIMD ops that produce reg_reg, reg_membase, reg_memindex
> variants, which
> don't have side effects and, finally, can be easily instantiated for the
> many vector elements.
> This is asking for a lot. But it would simplify the JIT a lot and make it
> produce better code easier.

See the attached program, it does already basically all the things you outlined.
All with half an hour of scripting and 60 lines of code.
So, no, there is no need for tablegen in mono, adapting it to hour needs
would require much more than half an hour and being so different is more
likely to introduce subtle issues.
Once the templates are defined, you can simply add a new SSE instruction
by addig its name to the proper list.


lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better
-------------- next part --------------
A non-text attachment was scrubbed...
Name: membase-map.pl
Type: text/x-perl
Size: 1875 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20100223/d8ba955c/attachment.bin 

More information about the Mono-devel-list mailing list