Does MSVC predefine __x86_64__ on 64-bit Intel?

I started wondering about $SUBJECT after noting that a very small
number of places in our code have tests like

#if defined(__x86_64__) || defined(__x86_64) || defined(_M_X64) /* gcc, msvc */

That's from src/include/port/atomics/arch-x86.h, and the last
two checks are demonstrably useless, because that whole file
only gets included if

#elif defined(__i386__) || defined(__i386) || defined(__x86_64__)
#include "port/atomics/arch-x86.h"

I did some googling and found

https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-180

which says nothing about either __i386__ or __x86_64__, but
does aver that

_M_X64 Defined as the integer literal value 100 for
compilations that target x64 processors or ARM64EC.
Otherwise, undefined.

So now I'm wondering if they predefine __i386__ or __x86_64__
and just don't feel a need to document that. If not, how
the heck does our code build on MSVC? Are we missing a whole
lot of CPU-specific optimizations there?

Also, after reading up on what ARM64EC means:

https://blogs.windows.com/windowsdeveloper/2021/06/28/announcing-arm64ec-building-native-and-interoperable-apps-for-windows-11-on-arm/

it seems like Microsoft has managed to break _M_X64 pretty
thoroughly, because now that symbol doesn't necessarily mean
that you're on Intel hardware. So I'm thinking we need to
transition away from depending on it to make architecture
choices. Not that we were doing so in very many places,
but it seems outright dangerous to use now: people might
cargo-cult use of that symbol into places where it's not
already certain that we're building for Intel.

Not being a Windows person, I can't easily answer these
questions by experiment. But I think they need answering
(and then documenting).

regards, tom lane