Further generalize the AssociativeCache

[giactra]

Generic Cache library The AssociativeCache introduced in https://github.com/gem5/gem5/pull/745 models a base associative storage managed by our existing indexing and replacement policies. At the moment the AssociativeCache is mainly used by several caching agents in the memory subsystem (e.g. prefetchers). One of the known limitations (as addressed in the aforementioned PR) is the lack of support for non Addr (uint64_t) tags. In other words the data structure APIs assume the entry template parameter is tagged with a single unsigned integer. This restricts the usage for other caching agents which for example use more complex tags (like TLB entries which are tagged based on a set of individual fields, like address, ASID etc).

@andysan suggested the following:

It would be a huge improvement if you could make the tag and lookup keys template parameters, but I don't know if this would be feasible in this PR though. It might have a large knock-on effect on the indexing policies.

I think what we need to truly generalise this is a way to specify the following:

• A lookup type. This could be a struct or Addr
• A hash function that works on the lookup type. Modern caches don't always use the text-book shift and mask approach. This may need to be a parameter.
• A comparison operator. In practice, we should probably store the entire lookup type as a tag instead of throwing away bits to save space. This would effectively require an operator== for the lookup type which would just work for many types.

As a concrete example, this would let you define a cache using the following pseudo-code:

struct CacheKey { uint16_t vmid; uint16_t asid; bool ns; Addr pa; };

uint64_t my_hash(const CacheKey &key) { return (key.pa >> bits) & mask_bits; }

AssociativeCache<CacheKey, my_hash> my_cache;

You'd then perform lookups using instances of CacheKey.

As has already been noted, one of the difficulties of implementing this is not in the cache per se, but in the interaction with the indexing policy SimObject , which is extracting the set number based on an unsigned integer 1. We would either have to deal with templated SimObjects or trying to find some other workaround