Re: [PATCH] lightning: Only optimize movr for regular registers

[Paul Cercueil]

Hi Paulo,

[...]


> > One improvement that I think would be great, is an optimization
> > pass
> > that would re-organize the emitted opcodes (after jit_emit). For
> > instance, to move memory loads as early as possible (before the
> > target
> > registers are used) to reduce pipeline stalls. In the case of
> > SuperH,
> > this would be very benefical as the architecture is superscalar,
> > but
> > not out-of-order - so the instructions have to be ordered cleverly
> > to
> > unlock the best performance.
> 
>   I do not know how SuperH works, but one idea could be something
> like
> what is done for the ia64 port, that keeps up to 3 pending
> instructions,
> then tries to best approach to run the instructions in a cycle. There
> are two bitmaps, one for registers and one for predicates. Probably
> can do something similar, but with more than 3 instructions, and
> flushing when encountering a conflict, label or branch. Anything more
> complex would  require another intermediate representation and could
> end up being too costly.

Thanks, that's helpful.

Another thing that I think could be better in Lightning, is forward
branches. At the moment where the branch is generated, you do not know
yet the exact target, so you have to emit opcodes that will support
very far targets, which can be costly on some archs.

I think it would be possible to compute the maximum distance to the
target, using the maximum size of each Lightning instruction between
the branch and the target. That's something that could be done arch-
independently. Then the code emitters for the branches could use this
information to deduce which opcode is best to use.

Cheers,
-Paul