Re: [Qemu-devel] Re: [PATCH 01/12] TCG "sync" op

[Aurelien Jarno]

On Wed, Nov 18, 2009 at 01:01:13AM +0100, Alexander Graf wrote:
>
> On 18.11.2009, at 00:40, Aurelien Jarno wrote:
>
>> On Wed, Nov 11, 2009 at 12:56:47AM +0000, Paul Brook wrote:
>>> On Thursday 22 October 2009, Aurelien Jarno wrote:
>>>> On Wed, Oct 21, 2009 at 03:52:22PM +0200, Ulrich Hecht wrote:
>>>>> sync allows concurrent accesses to locations in memory through  
>>>>> different
>>>>> TCG variables. This comes in handy when you are emulating CPU  
>>>>> registers
>>>>> that can be used as either 32 or 64 bit, as TCG doesn't know  
>>>>> anything
>>>>> about aliases. See the s390x target for an example.
>>>>>
>>>>> Fixed sync_i64 build failure on 32-bit targets.
>>>>
>>>> Looking more in details to the use case of this patch, I think it  
>>>> can be
>>>> useful in QEMU. However I don't feel very comfortable in merging it
>>>> without having the opinion of more persons. Paul, Malc Blue Swirl or
>>>> others, any opinion?
>>>
>>> I don't think this is the right solution.
>>>
>>> IIUC the basic problem is that we have a register file where  
>>> adjacent pairs of
>>> 32-bit registers are also accessed as a 64-bit value.  This is  
>>> something many
>>> other targets need to do (at least ARM, PPC, MIPS and SPARC).
>>>
>>> While sync appears attractive as a quick hack to achieve this, I  
>>> think it is
>>> liable to be abused, and cause us serious pain long-term. If you  
>>> need an easy
>>> solution then use ld/st (as with ARM VFP registers). If you want a  
>>> good
>>> solution then fix whichever bit of TCG makes accessing a pair of  
>>> registers
>>> horribly slow. We already have some support for this  
>>> (concat_i32_i64).
>>>
>>
>> What is probably needed here are merge_low and merge_high ops, merging 
>> a
>> 32-bit value into the low or high part of a 64-bit value, leaving the
>> other part unchanged. Not sure we can really optimize that on x86/ 
>> x86_64
>> compared to standard TCG code though.
>
> Maybe I got the whole point wrong but isn't this about having 2 virtual 
> register sets for the same target registers? So you'd have:
>
>  TCGvar my_reg_32;
>  TCGvar my_reg_64;
>
> and whenever you work with either of them you want to have the correct  
> value present in both (cut off for 32bit, extended for 64 bit).
>
> So what's really necessary is some internal coupling and dirty log of  
> variables within TCG so it knows that an access to the 64 bit of a  
> coupled variable means it needs to sync the 32 bit value over and vice  
> versa. Then magically everything would just work as expected.
>

That's an option, basically keeping the list (or only one ?) of aliased 
TCG variables for each of them, and freeing the others before using one.

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