As others have said, most names follow a pattern once you're used to it. The ARM NEON intrinsic names are better than Intel's. It's partly a consequence of trying to squish readable names into a global namespace for intrinsics that must be available from both C and C++ without overloading. And sometimes the names are obscure because the operations are obscure:

https://developer.arm.com/architectures/instruction-sets/intrinsics/vqrdmlah_s16

Wouldn't really help to have an intrinsic like signed_saturating_rounding_doubling_multiply_accumulate_high_half(). But there are other annoyances with common SIMD intrinsics, like:

Having the IDE give unhelpful (src1, src2, src3) as the arguments for a madd intrinsic because that's how the intrinsic was defined in the compiler header, only to cross-reference it to the documentation which lists them as a, b, and c, which then has to be translated to Vd, Vn, and Vm registers in order to match then to V[n], V[m], and V[d] and then operand1/2/3 in the pseudocode (in different order), in order to figure out which ones are the multiply terms and which one is the addend.

Accidentally triggering an illegal instruction because on Intel, despite regularly named intrinsics, 16-bit, 32-bit, and 64-bit logical shifts left and right are SSE2, 16-bit and 32-bit arithmetic shifts right are SSE2, but 64-bit arithmetic shifts right are AVX-512. Or similarly on ARM, finding out that a particular multiply intrinsic is ARMv8 while the multiply add intrinsic is ARMv8.1, and nowhere on the intrinsic page for the latter does it tell you that the madd version requires ARMv8.1 / FEAT_RDM unless you also cross-check the assembly instruction.

Having to type vreinterpretq_f32_u32(vandq_u32(vreinterpretq_u32_f32(vals), sign_mask)) because ARM decided to use the unwieldy "reinterpret" instead of "cast".

Having to do nasty pointer casts because Intel did silly things like have a 64-bit load intrinsic _mm_loadl_epi64 take a __m128i pointer even though it only loads 64 bits.