|
From: Julian S. <js...@ac...> - 2012-08-28 18:24:30
|
On Monday, August 27, 2012, Florian Krohm wrote:
> I'd like to auto-detect the cache configuration of the host machine for
> s390. So I was looking around how this is done on other architectures.
> Turns out, nobody does it except x86 and x86-64. These architectures get
> special treatment in form of VG_(cpuid). But that function is not
> portable to other architectures. On s390 I would need to know whether
> the host supports a certain insn. That info is present in the "hwcaps"
> field of VexArchInfo. But VexArchInfo is not passed to the tools.
The design philosophy (which may be flawed, but anyway) is that tools
really only need to be able to analyse and generate IR. They don't need
to be aware of the details of the architecture/cpu under simulation.
We abuse that wildly in Callgrind and Cachegrind, by allowing tools
to make their own attempts to establish the cache parameters. But I
would prefer not to perpetuate this abstraction-breakage by passing
VexArchInfo to tools.
And it doesn't make much sense for Callgrind/Cachegrind to have their
own CPU-querying code in
cachegrind/cg-{arm,mips32,ppc32,ppc64,s390x,x86-amd64}.c
when we already have a centralised facility to generally poke around
the host cpu and figure out what it can do, in coregrind/m_machine.c.
Overall, a cleanish refactoring seems to me to be to merge
cachegrind/cg-{arm,mips32,ppc32,ppc64,s390x,x86-amd64}.c
and have a new function, VG_(machine_get_cacheinfo) (as a peer
of VG_(machine_get_hwcaps)), that tools can call if they want
to get cache info. Then we could nuke VG_(has_cpuid) and also
write VG_(cpuid) using inline assembly, hence getting rid of
m_cpuid.S entirely.
None of which helps you in the short term, since it's quite a lot
of work to do that refactoring. The difficulty (and hence the
delay in reply to this msg) is that I'm not enthusiastic about
either (1) or (2) below.
How much refactoring effort are you prepared to go to at this point?
I wonder if there's a way to get you what you want without too much
effort, whilst at the same time moving incrementally in the
direction of centralising cache detection stuff in coregrind.
J
> Now what?
> (1) Pass VexArchInfo to the "instrument" function of the tool. That
> structure would convey whether or not the cache configuration of
> the host can be queried. A tool would then query that information
> in an architecture-specific way. For instance, we could amend
> VexArchInfo by adding a "Bool x86_amd64_has_cpuid" field. Cachegrind
> would then call VG_(cpuid) if that field is True. VG_(has_cpuid)
> would be obsolete.
>
> (2) Replace VG_(cpuid) with, say, VG_(cache_info) which would return
> information about the host's caches in a general way:
> - number of cache levels
> - for each cache level
> - split data/insn cache or not
> - line size
> - cache size
> - set associativity
> Also replace VG_(has_cpuid) with VG_(has_cache_info).
|