Add MSVC ARM64 support

[janisozaur]

Ran all the tests on my Raspberry Pi and it works fine. Results attached.

user_counters_thousands_test.txt
user_counters_test.txt
user_counters_tabular_test.txt
templated_fixture_test.txt
string_util_gtest.txt
statistics_gtest.txt
skip_with_error_test.txt
report_aggregates_only_test.txt
register_benchmark_test.txt
options_test.txt
multiple_ranges_test.txt
memory_manager_test.txt
map_test.txt
link_main_test.txt
internal_threading_test.txt
filter_test.txt

[janisozaur]

Ping

[LebedevRI]

I would personally say that upstream CMake should land the fix first.

[janisozaur]

That's a 6-year old issue and I haven't seen merge requests addressing it. I doubt fixing it upstream is on the horizon.

That said, cmake fix would be the best.

[LebedevRI]

Did anyone actually submit the patch upstream?
Either this is the right fix, and upstream will be okay with it,
or it's not and i'm not sure why wrong fix should be included into every downstream.

[janisozaur]

@LebedevRI I'm trying to get Google benchmark packaged for arm64 with MSVC using vcpkg, but they, understandably, don't want new features, just the packaging fixes.

So far you only voiced concerns regarding packaging, but nothing regarding the timing code itself. Would you accept a PR with just the C++ bits extracted from this one and leave this one for packaging/cmake only?

Do you have any expectation of what should be the next steps? I can look for any patches to address this problem in cmake and assess when it might get released. I don't intend to fix the guy theyü⁷

problem

[LebedevRI]

See my previous comment - did anyone actually tried to upstream that patch into CMake proper?

[janisozaur]

@LebedevRI as your comments are with regards to CMake, I've split this patch to add reading counter support here and cmake stuff now lives at #1090

[LebedevRI]

I trust that you have manually ensured that the benchmarking results are actually meaningful there.