|
From: Florian K. <br...@ac...> - 2012-10-15 03:46:10
Attachments:
vex-patch
valg-patch
|
Here is a followup patch to the cache reorganisation. It changes the cache detection for x86 / x86_64 such that all caches up to and including L3 are recorded in VexCacheInfo. Two new functions have been added: - cache_info_is_sensible: to check the autodetected cache info for feasibility - write_cache_info: to dump out what was detected for debugging I've moved the warnings about trace caches and the massaging of the cache size to cachegrind addressing a comment of Josef's. I did not add another cache kind for that; instead I added a is_trace_cache field to VexCache. Cache detection itself does not issue any warnings anymore. The reason is that cache detection happens all the time now and most tools do not need the information. So warnings about strange cache layouts and such would just be confusing. Some of those warnings have been moved to cachegrind. Others are now only visible with when -d is given. Cheers, Florian |
|
From: Josef W. <Jos...@gm...> - 2012-10-15 20:10:43
|
Hi Florian, Am 15.10.2012 05:45, schrieb Florian Krohm: > Here is a followup patch to the cache reorganisation. It changes the > cache detection for x86 / x86_64 such that all caches up to and > including L3 are recorded in VexCacheInfo. > > Two new functions have been added: > - cache_info_is_sensible: to check the autodetected cache info for > feasibility So if an autodetected cache info is not feasible, this is regarded as a bug? > - write_cache_info: to dump out what was detected for debugging > > I've moved the warnings about trace caches and the massaging of the > cache size to cachegrind addressing a comment of Josef's. I did not add > another cache kind for that; instead I added a is_trace_cache field to > VexCache. Fine with me. But note that trace caches are always about storing (already decoded) instructions. So this flag makes no sense with the other cache types. > Cache detection itself does not issue any warnings anymore. The reason > is that cache detection happens all the time now Isn't it just done when VG_(machine_get_cache_info) is called? Regarding the rest of the patch: looks fine reading it, but I did not compile. BTW, a "sectored cache" with Intel machines refered to a simple prefetch strategy. For read misses, it worked like having the doubled cache line size. Josef |
|
From: Florian K. <br...@ac...> - 2012-10-15 22:38:38
|
Hi Josef, On 10/15/2012 04:10 PM, Josef Weidendorfer wrote: >> >> Two new functions have been added: >> - cache_info_is_sensible: to check the autodetected cache info for >> feasibility > > So if an autodetected cache info is not feasible, this is regarded as > a bug? This is more of a safe-guard to make sure the auto-detect code does not stick something into VexCacheInfo that is bogus (for whatever reason). valgrind execution will continue as usual. Except that cachegrind won't find any caches. Actually, that is not quite true yet. I just realise that I forgot to empty out the VexCacheInfo stuff in case something infeasible was found. Consider that done. >> Cache detection itself does not issue any warnings anymore. The reason >> is that cache detection happens all the time now > > Isn't it just done when VG_(machine_get_cache_info) is called? Yes, but VG_(machine_get_cache_info) is called unconditionally from VG_(machine_get_hwcaps) which itself is called all the time. Florian |