|
From: Josef W. <Jos...@gm...> - 2012-10-01 14:40:47
|
Hi Florian,
Am 30.09.2012 19:17, schrieb Florian Krohm:
> - In cachegrind: Clarify what LL cache should be used when there are
> more that 3 levels in the cache hierarchy. Update docs.
See other mail (and below).
> - Improve cannot-autodetect warnings from cachegrind. They typically
> read like so:
>
> Warning: Cannot auto-detect cache config on MIPS32, using one
> or more defaults
>
> Mentioning an architecture is redundant as we run natively. And
> "using one or more defaults" is a usability disaster. Why not say
> *what* default?
I vote for
"Cannot auto-detect cache config, using defaults (run with -v to see)"
Just looking at reduced-valg-patch...
+ // FIXME: needs clarification for num_levels > 3 see also warning below
+ // FIXME: whether it needs adjustment
+ ll = locate_cache(ci, UNIFIED_CACHE, ci->num_levels);
+
+ if (ll && ci->num_levels > 2) {
+ VG_(dmsg)("warning: L%u cache found, using its data for the "
+ "L2 simulation.\n", ci->num_levels);
+ }
I think this warning should not talk about L2, but "LL" (last level).
Do we want to add "vg_assert(ci->num_levels>1);" here?
+ */
+static Int
+Intel_cache_info_aux(Int level, cache_t* I1c, cache_t* D1c, cache_t* LLc)
...
I think this should return both L2 and L3 data now.
There is also some code reinterpreting parameters of the
micro-ops trace cache on Intel P4 for L1. Such kind of using
auto-detected values in different ways should be in the tool.
To be able to do the same now, we need another cache kind
TRACE_CACHE, and cachegrind can check for this if there is
no info for an L1 INSN_CACHE.
On the other hand, not sure it's worth it.
Josef
|