Create a build-time mapping of module name strings to module types

To support runtime configuration, and possibly #546, we need a way to convert between the strings given in a configuration file ("hashed_perceptron", "lru", "ip_stride", etc.) to the type of the module object. As a stretch goal, we should see if we can map both directions.

There are a number of possible options, not all of which will work for our purposes.

Some solutions use __FUNCTION__ and parse the resulting string. (link)
Magic_enum also uses __FUNCSIG__. (link)
Since a string will be provided, it could be possible to create a constexpr function that lexicographically iterates through all possible identifiers, and returns a truthy value only for those which match a valid identifier. That might be totally off into the weeds, though.

Any solution must be generated at build-time, not at configure time, and callable at runtime.

Does here help at all? typeid(module).name() seems like it might work, but I am not sure.

Another option may be a global map.
Every module could have a static call to insert itself into the map, called once somewhere within its .h or .cc file.
A fully constructed map should allow us to associate a string with the module.
I know it might not be great for runtime, but we could then use typeid to do a reverse lookup to convert types to strings if necessary (or modules could have another function that just returns a predefined string when called).
This is something that seems like could be scaled well and shouldn't run into any weird edge cases. We could also assert that all entries into the map are unique, so if we have a collision we can quit out.

Getting the mangled name for the module also works if you use typeid(module).name(), but demangling doesn't seem like it has any great solutions if we want to avoid boost and support clang and MSVC.

I'm dubious regarding typeid. Its support has always been shaky, and the output format isn't very friendly.

We could modify the module base class constructors to the following:

class prefetcher {
protected:
template <typename Derived>
prefetcher(Derived* deriv_ptr, std::string deriv_name);
};

class ip_stride: public prefetcher {
public:
ip_stride() : prefetcher(this, "ip_stride") {}
};

... and then somehow map the strings to types. It's not clear to me how we would do that though. I'd have to think about it longer.

Do we necessarily need to map the strings to types? What are we trying to accomplish by knowing the type? If there were a way to have a function achieve what we want, then maybe we could map strings to function objects / functors?

We need to know the type so that we can instantiate the cache_builder or core_builder template parameters.

Can we use templates during runtime?

No, but we can do something clever like:

struct environment {
  static CACHE make_cache(cache_builder<no, lru> build, std::string pref, std::string repl) {
    if (pref == "ip_stride" && repl == "lru") return CACHE{build.prefetcher<ip_stride>().replacement<lru>()};
    if (pref == "spp_dev" && repl == "lru") return CACHE{build.prefetcher<spp_dev>().replacement<lru>()};
    //...
  }
};

Of course, you have talked about virtualizing the member hooks, which would mean we could just pass around a prefetcher* and a replacement*, but we still need to relate the string to a type to instantiate the subclass.

What I am saying is maybe the instantiation can be passed off to something the prefetcher can insert into the map. Not sure exactly what, but maybe a templated function object or something like that? Then invoke that particular entry in the map to construct a specific module.

Navigation Menu

Repository navigation

Create a build-time mapping of module name strings to module types #548

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Create a build-time mapping of module name strings to module types #548

Description

Activity

maccoymerrell commented on Nov 16, 2024

maccoymerrell commented on Nov 16, 2024

ngober commented on Nov 18, 2024

maccoymerrell commented on Nov 18, 2024

ngober commented on Nov 18, 2024

maccoymerrell commented on Nov 18, 2024

ngober commented on Nov 18, 2024

maccoymerrell commented on Nov 18, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions