qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/6] AREG0 patches v4


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH 0/6] AREG0 patches v4
Date: Sun, 8 Jan 2012 12:27:39 +0000

On Sun, Jan 8, 2012 at 00:52, Aurelien Jarno <address@hidden> wrote:
> On Sat, Jan 07, 2012 at 10:24:09PM +0000, Blue Swirl wrote:
>> In this version, I made basic AREG0 free load/store implementations
>> for all targets. Only x86-64 is tested, others have probably problems,
>> especially 64 bit guest (Sparc64 in this case) on 32 bit hosts.
>>
>> I think this should be committed as a starting point if there are no
>> major objections.
>>
>
> If it is known to be broken on 32-bit hosts, I am not sure it's really
> a good idea to commit these patches. It's just going to prevent all
> people developing on x86 to continue testing or developing QEMU.

No, the brokenness is limited to 32 bit hosts with 64 bit AREG0 free
targets, which currently means Sparc64 on i386, Sparc64 on ARM etc.
Sparc32 should run unless there are other problems. Other targets
which are not AREG0 free (like x86) should be unchanged on any host.

I'm not familiar with various host ABIs, fixing all of the targets is too much.

> Also I have to say I still don't get the goal of these patch series. I
> have just tried it on an x86-64 guest with a 32-bit sparc guest. It
> works well, but the generated TB are slightly bigger. I have done a
> quick and dirty performance test by compiling some code inside the
> guests, and I get a slow down of about 0.6%, though for this kind of
> performance changes, it should probably done with other methods.

Thank you for testing. I also made some tests earlier which were near
that figure but there performance increased. But my test setup adds a
lot of noise (CPU throttling etc.) so I didn't trust the figures much.

The slow down could come from changed compiler flags. IIRC looking at
disassembled functions, stack protector kicks in.

> Is there another goal behind this patch series beside performance?

Yes, we eliminate the global register variable, which has given us a
lot of trouble. Those are not supported by for example LLVM or sparse.
The semantics of calling code which has not been compiled with
register variables from code which has been compiled so is not
defined, but it happens to work most of the time by saving the
variable by hand. On Sparc hosts, global register handling is a mess.

After the change has been made, all QEMU code is just plain C. With
TCI it should even be portable to any host.

When AREG0 is only used internally to TCG generated code, we could
even put the CPUState structure to stack and use stack pointer to
access them, freeing a global variable there too.

> --
> Aurelien Jarno                          GPG: 1024D/F1BCDB73
> address@hidden                 http://www.aurel32.net



reply via email to

[Prev in Thread] Current Thread [Next in Thread]