Introduce loongarch32 target triple and __loongarch_ilp32

[jiegec]

Introduce loongarch32 target triples with the same format as loongarch64, but with ilp32[d|f|s] abi. __loongarch_ilp32 macro is added.

[zhuchen1911]

Thank you for your comments, we are still discussing the specification of LoongArch32.

[zhuchen1911]

Thank you for your comment. The related content of Loongarch32 is still under internal evaluation and will be added at the appropriate time in the future.

[xen0n]

For the record: I personally would not in general object to Loongson's desire to "polish up" things before declaring them official, but that does NOT mean I would accept postponing things purely according to internal agenda.

Sure, ABI stability and support guarantee are extremely important, but I think it's not implying blocking of progress. For example, we could add a compilation flag like -mloongarch-unstable-feature=20241217 to enable the user:

• to explicitly opt-in to unstability and corresponding maintenance,
• to signify the exact behavior they're expecting, even in the face of potential breaking changes in the future,

while still allowing the ABI to freely evolve before stability can be declared.

We can find examples of this approach in the Rust ecosystem:

• unstable features are only available in the nightly channel;
• unstable compiler features are specified with -Z xxx instead of -C xxx, and only available with nightly compilers;
• the gcc-rs frontend is only usable with a rather descriptive -frust-incomplete-and-experimental-compiler-do-not-use flag.

While it can seem very annoying to some, this approach objectively allows stability and free evolution of experimental features at the same time.

[xen0n]

And in my opinion, LA32R hardware is still in production and active use, both today and many years to come, and every year newcomer students are going to learn and make LA32R cores for Loongson Cup. Being able to use upstream resources is a huge productivity boost to the LA32R community, and according to loongson-community/discussions#65 it's already ~2 years since I first advocated for upstreaming LA32R support. I don't think it's wise to delay any longer, it will not benefit anyone.

[chenhuacai]

This work is delayed for too long time, I think it is time to let LoongArch32 be upstream now, and the changes look good to me. Thanks.

[zhuchen1911]

Modifications to this document are subject to department and company review, and I do not have the authority to approve this merge request.

[xen0n]

Modifications to this document are subject to department and company review, and I do not have the authority to approve this merge request.

Then maybe just leave it open? According to community standards closing an issue or a PR basically means "it was rejected by us", but based on your own words, you don't have the authority to do that either.

[FlyGoat]

+1 for fast forwarding this specification update.

I’m currently working on LA32/32R stuff and had been using LLVM toolchain’s “experimental” ilp32s support for a while. I’d love to see the specification being ratified.

[zhuchen1911]

After la-toolchain-conventions and la-eabi-specs complete the related content of LoongArch32, there will be a basis for modifying this convention. Because the relevant content of this agreement is quoted from the above specifications.