x64: Backend-specific user configurations

[Wunkolo]

Backend-specific enums like HostFeature should be exposed to the user such that particular backend-specific features can be toggled on/off and to relief the backend code the responsibility of things like checking if the host supports FastBMI2.

dynarmic/src/dynarmic/backend/x64/block_of_code.cpp

Lines 165 to 179 in ff47d0d

	if (cpu_info.has(Cpu::tBMI2)) {
	// BMI2 instructions such as pdep and pext have been very slow up until Zen 3.
	// Check for Zen 3 or newer by its family (0x19).
	// See also: https://en.wikichip.org/wiki/amd/cpuid
	if (cpu_info.has(Cpu::tAMD)) {
	std::array<u32, 4> data{};
	cpu_info.getCpuid(1, data.data());
	const u32 family_base = mcl::bit::get_bits<8, 11>(data[0]);
	const u32 family_extended = mcl::bit::get_bits<20, 27>(data[0]);
	const u32 family = family_base + family_extended;
	if (family >= 0x19)
	features |= HostFeature::FastBMI2;
	} else {
	features |= HostFeature::FastBMI2;
	}

Backend-specific configuration structures could possibly exist as a field within the current A{32,64}::UserConfig structures as a void* backend_config to avoid leaking too-many backend-specific code and structures to the user's codebase and to allow for future backends to have their own configuration structure(think of Vulkan's pNext pattern).

The current use-case for backend-specific configurations that I have in mind would allow for Yuzu to turn on/off certain host-features like AVX512, BMI2(and checking for pre-Zen3 hardware), WAITPKG, usage of ymm/zmm registers, and possibly allow for configuring of things like finding an optimal const-pool size or address some other magic-numbers across the code-base.

dynarmic/src/dynarmic/backend/x64/block_of_code.cpp

Line 51 in ff47d0d

constexpr size_t CONSTANT_POOL_SIZE = 2 * 1024 * 1024;

This would also be great for debugging and profiling particular ISA-features and implementations or mitigating feature-bugs out in the field(if a feature behind the HostFeature::COOLFEATURE flag introduced a bug after releasing to the public, then users could be advised to just turn off HostFeature::COOLFEATURE until it is fixed).

[merryhime]

Backend-specific configuration structures could possibly exist as a field within the current A{32,64}::UserConfig structures as a void* backend_config to avoid leaking too-many backend-specific code and structures to the user's codebase and to allow for future backends to have their own configuration structure(think of Vulkan's pNext pattern).

std::any is perfect for this usecase.