Re: [Qemu-devel] Re: [PATCH 2/3] target-sparc: Free instruction temporaries.

[Blue Swirl]

On 4/17/10, Richard Henderson <address@hidden> wrote:
> On 04/17/2010 11:41 AM, Blue Swirl wrote:
>  > About this patch: it's good that we now free the constants, but
>  > constant handling is still not optimal and I think this series
>  > actually may add extra 'movi' ops in the worst case. It would be nice
>  > if we detected if constants are in play and call immediate versions
>  > (addi, subi etc) automatically. This may need bigger refactoring,
>  > though.
>
>
> No, that won't help, since the first thing that addi, subi, etc
>  do is to load the constant into a temporary.

Yes, but we would still gain the small optimizations for add by 0, and
with 0xffffffff etc. in tcg-op.h. Sparc QEMU target generates a lot of
those because of poor constant formation choices made by the guest
compilers.

>  What would *really* help though, is something along the lines of
>  Aurelien's constant propagation patch, followed by some mechanism
>  to refactor constants in the backend.
>
>  Aurelien's patch does a good job of building the full constant
>  that the RISC instruction stream needed to use to generate the
>  full 32-bit or 64-bit constant.  If the host is x86, that's just
>  about all we need.  However, if the host is a RISC, we'll
>  generally need to decompose the constant again.
>
>  I've got the outline of an idea by which TCG can remember which
>  constants are actually loaded into registers.  And it should be
>  designed so that the host backend can call into it to load other
>  constants.  In this way when we have a pair of constants like
>
>   0xfff00011
>   0xfff00022
>
>  the sparc backend can (if things go well with register allocation)
>  load the %hi(0xfff00000) just once, and form the full constants
>  with addition from there.

That should be interesting.

By the way, do you think constant pool approach (put constants at the
end of TB) would be useful, especially for 64 bit constants?