|
From: Florian K. <br...@ac...> - 2012-09-21 17:01:27
|
We had a discussion about this a few weeks back. Here are my thoughts.
Objective:
----------
Have coregrind query the properties of the host's cache system. Make
this information available in a simple interface that hides all
architecture-specific details e.g. the existence of a cpuid instruction.
Benefits:
---------
This is conceptually cleaner than the status quo. Detection of cache
properties does not belong in the realm of the tools. Additionally,
if several tools required information about caches there would be code
duplication.
Representation of cache information:
------------------------------------
/* The various kinds of caches */
typedef enum {
DATA_CACHE,
INSN_CACHE,
DATA_INSN_CACHE // combined data and insn cache
} cache_kind;
/* Information about a particular cache */
typedef struct {
cache_kind kind;
UInt level; /* level this cache is at, e.g. 1 for L1 cache */
UInt sizeB; /* size of this cache in bytes */
UInt line_sizeB; /* cache line size in bytes */
UInt associativity;
} cache_t;
/* Information about the cache system as a whole */
typedef struct {
UInt num_levels;
UInt num_caches;
/* Unordered array of caches for this host. NULL if there are
no caches. Users can assume that the array contains at most one
cache of a given kind per cache level. */
cache_t *caches;
} cacheinfo_t;
What is shown here has all the info that is needed for cachegrind
and callgrind purposes. It can trivially be extended to provide more
detail if that becomes necessary. Clearly, arranging the data this
way will be easy on some architectures and more cumbersome on others.
The objective is that it should be easy for the users to extract what
they need. The code to build up this data would reside in m_machine.c.
Users of cache information:
---------------------------
I found at least these (there may be more):
(1) cachegrind / callgrind
These are perfectly served by cacheinfo_t as shown above.
(2) VG_(invalidate_icache)
We need to extend the above representation, by, say, adding a
"Bool icaches_maintain_coherence;" to cacheinfo_t
(3) VEX: VexArchinfo contains ppc_cache_line_szB
The cache line size is needed to implement the icbi insn.
Can be obtained from cacheinfo_t
(4) VEX: functions returning VexInvalRange
The returned address range indicates whether some cache invalidation
needs to occur later. What is returned here may, in general, depend
on the particular machine model of a given architecture. So we need
to query the cache info before returning anything.
A different possibility, which may even be cleaner, is to make these
functions *always* return the address range for the insns that were
patched. In that case we would not need cache information here. The
call site would decide about invalidation.
How to make cache information available:
----------------------------------------
Ideally we want the cache information to be provided in one spot only;
be that a function call returning it or some persistent data structure
containing it. A related question is where the definition of cacheinfo_t
resides. If it does not reside in VEX then VEX would be dependent on
coregrind and that's a no-go. So, adding a cacheinfo_t typed member
to VexArchInfo looks natural. It could be filled in the same way hwcaps
are currently filled in in m_machine.c.
The type definitions (cache_t, cacheinfo_t etc) would be included in
libvex.h
Tools can call the existing VG_(machine_get_VexArchInfo) to get the
cache information. The function would have to be exposed through
pub_tool_machine.h so it becomes available.
Alternatively, VexArchInfo could be passed to the "instrument" function
of the tools.
Cache information will be determined after hwcaps and machine models
have been determined. The rationale is that not all cache information
can be figured out automatically (e.g. on s390 we cannot figure out
whether icaches are coherent). Some such information may depend on
the machine model (part of hwcaps) for which we just know what it is and
can fill it in.
I can work on an implementation for this but first there should be
agreement
- about the data structures to represent cache info
- how tools access it (function call or passed to the instrument
function)
Florian
|