[llvm] [LoongArch] Enable FeatureExtLSX for generic-la64 processor (PR #113421)

[WÁNG Xuěruì via llvm-commits]

https://github.com/xen0n approved this pull request.

> AFAIK, the upcoming [soft-dev-conv](https://github.com/loongson/la-softdev-convention) requires developers must enable LSX by default when building desktop and server operating systems (but not for embedded systems).

Upcoming? Indeed it seems so because v0.1 [says](https://github.com/loongson/la-softdev-convention/blob/v0.1/la-softdev-convention.adoc#101-desktop-and-server-operating-system-build-requirements) "should".

This matters mostly from a business perspective, more so than the technical (performance) perspective, because one of the indirect consequences of *mandating* LSX (without also mandating scalar fallbacks be provided for all code) is that a body of closed-source LSX-containing components will begin to form, forcing the ecosystem building upon it to require LSX as well. This allows for easy market segmentation by e.g. providing specific CPU models without LSX/LASX -- while being lower-priced overall, they cannot run most general-purpose distributions unmodified, and even if the devs went to the great length of assembling a sysroot themselves e.g. with buildroot, they'd be still out of luck if their business depends on a closed-source blob requiring LSX. And with certain LSX/LASX features likely patent-encumbered, this makes third-party LoongArch implementations less competitive as well.

However, the status quo is already LSX all over the place -- `memcpy`/`memset` getting auto-vectorized once it's enable-by-default -- as one can verify on Compiler Explorer on on their own machine. In this case having consistency is probably better, and we should approach the embedded/indie-core problem separately.

As I have now verified several important `-march` choices to match GCC behavior for a piece of trivial loop eligible for vectorization (simple i32 adds):

* no `-march` given: LSX
* `-march=loongarch64`: scalar
* `-march=la64v1.0`: LSX

I'm accepting the patch as well. Thanks!

https://github.com/llvm/llvm-project/pull/113421