[Qemu-devel] TCG

[Qemu-devel] TCG

[Fabrice Bellard]

Hi,

I added a new code generator (TCG) in QEMU. Read the file 
qemu/tcg/README to have technical information. A new code generator was 
needed in order to avoid problems with the various GCC versions and to 
get better performance.

I made minimal modifications in each target so that they can still work 
by using TCG and legacy "dyngen" micro operations. More work will be 
needed to convert each target to TCG, but it can be done progressively. 
Only the x86 and x86_64 targets have been significantly modified to use TCG.

TCG currently only supports x86 and x86_64 hosts. The support of other 
hosts is broken in QEMU. I don't consider it is a priority to support 
other hosts although TCG is generic enough to allow it.

The performance should not change much at this point. On x86_64 hosts, 
the x86 and x86_64 targets are faster because of some assembly language 
optimizations. On x86 hosts, the x86_64 target is faster because TCG can 
do some optimizations related to the conversion from 64 to 32 bits. No 
performance change should be noticed on non x86 targets because they are 
not converted yet.

Fabrice.

Re: [Qemu-devel] TCG

[C.W. Betts]

Well, it compiles fine on Windows using gcc 3.4.5.  Haven't tried Linux yet.
----- Original Message ----- 
From: "Fabrice Bellard" <fabrice@bellard.org>
To: <qemu-devel@nongnu.org>
Sent: Friday, February 01, 2008 6:13 AM
Subject: [Qemu-devel] TCG


> Hi,
>
> I added a new code generator (TCG) in QEMU. Read the file qemu/tcg/README 
> to have technical information. A new code generator was needed in order to 
> avoid problems with the various GCC versions and to get better 
> performance.
>
> I made minimal modifications in each target so that they can still work by 
> using TCG and legacy "dyngen" micro operations. More work will be needed 
> to convert each target to TCG, but it can be done progressively. Only the 
> x86 and x86_64 targets have been significantly modified to use TCG.
>
> TCG currently only supports x86 and x86_64 hosts. The support of other 
> hosts is broken in QEMU. I don't consider it is a priority to support 
> other hosts although TCG is generic enough to allow it.
>
> The performance should not change much at this point. On x86_64 hosts, the 
> x86 and x86_64 targets are faster because of some assembly language 
> optimizations. On x86 hosts, the x86_64 target is faster because TCG can 
> do some optimizations related to the conversion from 64 to 32 bits. No 
> performance change should be noticed on non x86 targets because they are 
> not converted yet.
>
> Fabrice.
>
>
>
> 

Re: [Qemu-devel] TCG

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3336 bytes --]

Hi,

here it bails out:

--  snip --
gcc -Wall -O2 -g -fno-strict-aliasing  -fno-reorder-blocks  -fno-gcse  
-fno-tree-ch  -fno-optimize-sibling-calls  -fno-crossjumping  
-fno-align-labels  -fno-align-jumps  -fno-align-functions   
-mpreferred-stack-boundary=2 -fomit-frame-pointer 
-DCONFIG_HAS_LINUX_COMPILER_H=1 -m32 -I. -I.. -I/home/qemu/target-i386 
-I/home/qemu -MMD -MP -DNEED_CPU_H -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -I/home/qemu/tcg -I/home/qemu/tcg/i386 
-I/home/qemu/fpu -I/home/qemu/linux-user -I/home/qemu/linux-user/i386 -c 
-o op.o /home/qemu/target-i386/op.c
/home/qemu/target-i386/ops_sse.h: In function ‘op_pshufw_mmx’:
/home/qemu/target-i386/ops_sse.h:593: error: unable to find a register to 
spill in class ‘GENERAL_REGS’
/home/qemu/target-i386/ops_sse.h:593: error: this is the insn:
(insn:HI 17 16 18 0 /home/qemu/target-i386/ops_sse.h:588 (set 
(strict_low_part (subreg:HI (reg/v:DI 63 [ r ]) 0))
        (mem/s/j:HI (plus:SI (mult:SI (reg:SI 64)
                    (const_int 2 [0x2]))
                (reg/v/f:SI 59 [ s ])) [0 <variable>._w S2 A16])) 40 
{*movstricthi_1} (insn_list:REG_DEP_TRUE 51 (insn_list:REG_DEP_TRUE 12 
(insn_list:REG_DEP_TRUE 16 (nil))))
    (expr_list:REG_DEAD (reg:SI 64)
        (nil)))
/home/qemu/target-i386/ops_sse.h:593: confused by earlier errors, bailing 
out
-- snap --



and in i386-softmmu it is similar:



-- snip --
gcc -Wall -O2 -g -fno-strict-aliasing  -fno-reorder-blocks  -fno-gcse  
-fno-tree-ch  -fno-optimize-sibling-calls  -fno-crossjumping  
-fno-align-labels  -fno-align-jumps  -fno-align-functions   
-mpreferred-stack-boundary=2 -fomit-frame-pointer 
-DCONFIG_HAS_LINUX_COMPILER_H=1 -m32 -I. -I.. -I/home/qemu/target-i386 
-I/home/qemu -MMD -MP -DNEED_CPU_H -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -I/home/qemu/tcg -I/home/qemu/tcg/i386 
-I/home/qemu/fpu  -DHAS_AUDIO -DHAS_AUDIO_CHOICE -I/home/qemu/slirp -c -o 
op.o /home/qemu/target-i386/op.c
/home/qemu/target-i386/ops_template_mem.h: In function 
‘op_cmpxchgb_kernel_T0_T1_EAX_cc’:
../softmmu_header.h:170: error: can't find a register in class ‘Q_REGS’ 
while reloading ‘asm’
-- snap --



This is on OpenSUSE 10.2, gcc (GCC) 4.1.2 20061115 (prerelease) (SUSE 
Linux), with "./configure --disable-gcc-check", and this patch on top of 
"<bellard>: typos, Fri Feb 1 13:01:47 2008 +0000":



-- snip --
[PATCH] Some Linux setups need linux/compiler.h; if it exists, include it

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 configure   |    3 +++
 usb-linux.c |    3 +++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index bcb958d..330020d 100755
--- a/configure
+++ b/configure
@@ -194,6 +194,9 @@ linux_user="yes"
 if [ "$cpu" = "i386" -o "$cpu" = "x86_64" ] ; then
     kqemu="yes"
 fi
+if [ -f /usr/include/linux/compiler.h ] ; then
+    OS_CFLAGS="-DCONFIG_HAS_LINUX_COMPILER_H=1"
+fi
 ;;
 esac
 
diff --git a/usb-linux.c b/usb-linux.c
index d3e4e2e..68fdbd2 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -28,6 +28,9 @@
 #if defined(__linux__)
 #include <dirent.h>
 #include <sys/ioctl.h>
+#ifdef CONFIG_HAS_LINUX_COMPILER_H
+#include <linux/compiler.h>
+#endif
 #include <linux/usbdevice_fs.h>
 #include <linux/version.h>
 #include <signal.h>
-- 
1.5.4.rc5.32.gc7b9
-- snap --



Ciao,
Dscho

Re: [Qemu-devel] TCG

[Paul Brook]

> I made minimal modifications in each target so that they can still work
> by using TCG and legacy "dyngen" micro operations. More work will be
> needed to convert each target to TCG, but it can be done progressively.
> Only the x86 and x86_64 targets have been significantly modified to use
> TCG.

When playing with this a bit with the ARM target I found it very easy to get 
variables, immediate values and register indexes mixed up. e.g. using 
gen_add_i32 instead of gen_add_i32, or gen_mov_i32(foo, rn) instead of 
gen_ld_i32(foo, cpu_env, offsetof(CPUState, regs[rn]).

Would you object to a patch that changed then gen_* functions in tgc_op to use 
an opaque type for variables? For performance reasons we probably want to 
keep it as an in in production builds, but for debugging it's nice to be able 
to catch the types of error mentioned above.  IMHO it also helps to improve 
the clarity of the code.

The changes should be mostly mechanical.

Paul

[Qemu-devel] Re: TCG

[Alejandro Mery]

I'm having the same problem over CVS's HEAD but my kernel is newer and I don't
have linux/compiler.h ... any hint? please :(

Thanks,
Alejandro Mery