was in the sigframe module has been moved into the coredump module
where it belongs and things fixed up to compiler again.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4970
be part of a self-check. Instead, copy verbatim any IR preamble
preceding the first IMark. This stops cachegrind asserting on
self-checking translations.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4967
it can't even read the length of the block - just report an error as we
do if there isn't enough data for the rest of the block. Fix bug #114757.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4960
unique / 30000 total to 1000 unique / 100000 total. Programs are
generally bigger now than 3 years ago.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4957
go, but realistically we can't implement it portably, at least without
considerable performance overhead and some additional complexity.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4956
monster-sized programs better, increase the default freelist volume
from 1M to 5M. Maybe even that is too small.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4954
performance quite a bit, since the cache is emptied quite often on
ppc32, and a smaller cache is less intrusive in the real machine's L2
cache. On x86 the change doesn't seem to have much effect.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4947
the guest extents for the presented translation and also its original
un-redirected guest address. These changes are needed in particular
to make cachegrind's code cache management work properly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4943
find and delete all translations intersecting with small address
ranges (8 k or less, currently). This makes it possible to simulate
ppc32 icbi instructions in reasonable time, and finally makes the
ppc32 port run at a usable speed.
The scheme is based around partitioning translations into equivalence
classes based on address ranges. For deletions whose range falls
within a single class, all translations intersecting it can be found
by inspecting just that class and one other. Given that there are 256
classes, this cuts the cost, relative to scanning the entire TC, by
approximately half that factor (viz, 128), assuming the translations
are distributed evenly over the classes.
The whole business is more complex and difficult than I would like.
A detailed comment will later be added.
Very thorough sanity checking has been added
(sanity_check_eclasses_in_sector). This is engaged at
--sanity-level=4 and above.
The TT hash function (HASH_TT) has been improved to reduce its
tendency to cluster TT entries in some circumstances. This has
allowed the TT maximum loading factor to be increased from 66% to 80%
and so the absolute size of the TC (in each sector) to be less than
2^16 entries. The latter change is important for the fast-deletion
changes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4942
instr_size and instr_addr) into Ir events, then later copying those into
instrInfo nodes. Now it just allocates the instrInfo nodes earlier and
copies them in directly. This is a bit more concise and easier to
understand.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4937
- Remove some unnecessary assertions.
- Add in some new ones.
- Make things more concise and readable by factoring out things like
"cgs->events[i+1]" into things like "ev2" in flushEvents().
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4936
- The instrInfoTable was a VgHashTable, now it's an OSet.
- The CC table was a custom 3-level hash table, now it's an OSet. This
is easier to understand and there's no worrying about whether the hash
array sizes are big enough. It also has the nice property that the
results in the cachegrind.out.<pid> file are now sorted, so they're a bit
easier to read.
I did some testing and the performance difference appears to be negligible;
CC table and InstrInfo table lookups and traversal aren't that critical.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4933
