Re: [Qemu-devel] [PATCH 5/x] ppc: Convert op_load_gpr_{T0, T1, T2} to TCG

["Aurélien Jarno" <aurelien@aurel32.net>]

On Wed, Sep 03, 2008 at 12:41:01PM +0200, Andreas Färber wrote:
> 
> Am 03.09.2008 um 07:07 schrieb Aurelien Jarno:
> 
> >On Wed, Sep 03, 2008 at 02:39:52AM +0200, Andreas Färber wrote:
> >>
> >>Am 03.09.2008 um 01:20 schrieb Aurelien Jarno:
> >>
> >>>
> >>>>+    for (i = 0; i < 32; i++) {
> >>>>+        cpu_gpr[i] = tcg_global_mem_new(TCG_TYPE_TL, TCG_AREG0,
> >>>>+                                        offsetof(CPUState,  
> >>>>gpr[i]),
> >>>>+                                        gprnames[i]);
> >>>
> >>>This is most probably wrong given the definition of ppc_gpr_t in
> >>>cpu.h:
> >>>- 64 bits on 64-bit targets
> >>>- 32 bits on 32-bit targets and 32-bit hosts
> >>>- *64 bits* on 32-bit targets and 64-bit hosts
> >>>
> >>>I think it is a bit weird, and I think the best is to modify cpu.h  
> >>>in
> >>>order to have ppc_gpr_t matching the target bitness.
> >>
> >>This might be related to the 64-on-32 issue I just posted about. I  
> >>don't
> >>remember seeing code that makes use of this sophisticated definition
> >>though, for non-ppc64 it apparently uses a set of 32-bit gpr and gprh
> >>variables. Let's not change ppc_gpr_t for now.
> >
> >Well that's different, your previous post is about T_* registers, I am
> >speaking about the GPR registers. And either ppc_gpr_t or the init  
> >code
> >of cpu_gpr[i] has to be changed, otherwise you will break existing
> >targets.
> 
> I'm quite sure it is related - the issue is that GPR / T TCGv size  
> does not always correspond to tl, and the only problem is the 32-bit  
> target with 64-bit host.
> 
> Would there be a problem with using i64 in the 32-on-64 case? That is,  
> would it hurt to do i32 TCG operations on i64 variables on a 64-bit  
> host? If not, we could keep tl for the regular instructions and use  
> i64 for ppc64/ppc-on-64 and 2x i32 on ppc-on-32. That sounds more  
> efficient than reverting the ppc_gpr_t optimization and always using  
> 2x i32 independent of the host bitness. We'll need an inlined helper  
> for these any way.

This optimization has been done with dyngen in mind, we surely don't
want to keep it with TCG.

I currently have plenty of time, but almost no network (travelling), so
I'll work on implementing a solution, and commit the result most probably
tomorrow morning.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net