more cache friendly. This changes the mechanism from being a table of
pointers to (guest address, translated code pairs) to being a table of
pairs (guest address, pointer to translated code). The effect ranges
from zero up to about 20% performance improvement on memcheck, the
biggest effects being seen for programs which jump around a large
number of blocks of code and whose data set does not fit in L2.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6582
Use 'ctr' rather than 'lr' for indirect jumps, so as not to trash the
branch predictor(s) for returns from generated code. Makes a big
difference on ppc970 (and POWER4).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6291
to the extent needed to make ppc32 work.
* As a result, remove the replacements for glibc's floor/ceil fns on
ppc32/64, since vex can now correctly simulate the real ones.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5605
perf/tinycc.
- run_thread_for_a_while: just clear this thread's reservation when
starting, not all of them.
- use a different fast-cache hashing function for ppc32/64 than for
x86/amd64. This allows the former to use all the fast-cache entries
rather than just 1/4 of them.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5441
- fixed launcher.c to recognise ppc32/64-linux platforms properly
- lots of assembly fixes to handle func descriptors, toc references, 64bit regs.
- fixed var types in vki-ppc64-linux
Now gets as far as VG_(translate), but dies from a case of invalid orig_addr.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5299
- Non-Java mode is the system default, but was causing some accuracy problems by rounding off intermediate denormalised results to zero.
We now have some small errors (lowest bit only) due to using greater accuracy than the system default, but is better overall.
Also expanded dispatcher check of FPSCR to include all contol bits
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5196
add a bunch of code to detect what the cpu can do at startup by
catching SIGILLs. Shame PPC doesn't offer any sane mechanism for
finding out what instruction subsets the CPU is capable of (a la
x86/amd64 cpuid).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5108
as requested by Greg Parker. (The ppc32/Darwin dispatch loop is
different to the ppc32/Linux one, for example.)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4843
