From 8cfca5c0194cf16d87784a77dd77b67a2e2217f8 Mon Sep 17 00:00:00 2001 From: Julian Seward Date: Wed, 6 Apr 2005 10:27:11 +0000 Subject: [PATCH] Comment-only changes git-svn-id: svn://svn.valgrind.org/vex/trunk@1124 --- VEX/priv/guest-x86/toIR.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/VEX/priv/guest-x86/toIR.c b/VEX/priv/guest-x86/toIR.c index 1b4681fd1b..39c51ffb89 100644 --- a/VEX/priv/guest-x86/toIR.c +++ b/VEX/priv/guest-x86/toIR.c @@ -34,7 +34,7 @@ */ /* TODO: - SBB reg with itself + SBB reg with itself (copy from amd64 front end) check flag settings for cmpxchg FUCOMI(P): what happens to A and S flags? Currently are forced @@ -64,7 +64,7 @@ zeroes all the FP registers. It should leave the registers unchanged. - RDTSC returns zero, always. + RDTSC returns one, always. SAHF should cause eflags[1] == 1, and in fact it produces 0. As per Intel docs this bit has no meaning anyway. Since PUSHF is the @@ -80,6 +80,21 @@ translate x86 code for execution on a 64-bit host. */ +/* Performance holes: + + - fcom ; fstsw %ax ; sahf + sahf does not update the O flag (sigh) and so O needs to + be computed. This is done expensively; it would be better + to have a calculate_eflags_o helper. + + - emwarns; some FP codes can generate huge numbers of these + if the fpucw is changed in an inner loop. It would be + better for the guest state to have an emwarn-enable reg + which can be set zero or nonzero. If it is zero, emwarns + are not flagged, and instead control just flows all the + way through bbs as usual. +*/ + /* Translates x86 code to IR. */ #include "libvex_basictypes.h" -- 2.47.3