Promote loongarch64-unknown-none* to Tier 2

[heiher]

MCP: rust-lang/compiler-team#664

[rustbot]

r? @JohnTitor

(rustbot has picked a reviewer for you, use r? to override)

[heiher]

Could you please trigger a try build?

[compiler-errors]

@bors try

[bors]

⌛ Trying commit afb9e961c4d0852daca63b67c72ca13283a2ae1a with merge 33a6d20727ff80d19d8e4fb41f083039d4555a55...

[bors]

☀️ Try build successful - checks-actions
Build commit: 33a6d20727ff80d19d8e4fb41f083039d4555a55 (33a6d20727ff80d19d8e4fb41f083039d4555a55)

[RalfJung]

Potential blockers:
#115509
#115609

EDIT: I didn't realize that we already have a tier 2 loongarch target. I guess adding more of them doesn't make this any worse. Ideally this would have had a more careful ABI audit before becoming tier 2.

[JohnTitor]

r? compiler

[oli-obk]

r? @wesleywiser as the MCP seconder

[heiher]

@wesleywiser gentle ping

[heiher]

Now, #115509 has been resolved, and #115609 is still in progress.

Quote @cuviper's comment:

the -linux-gnu target is already tier 2, so I don't see why those issues would block -none

I request that #115609 is not considered a blocker.

[heiher]

r? @Mark-Simulacrum "Promotion" may have more to do with infrastructure.

I see that only a small amount of library code needs to be compiled for the bare metal target, which puts very little pressure on the build. The 1.74 version will be branched off from the master on Sep 29th. Could you please review this before then? 😃

[wesleywiser]

The compiler team has approved the MCP for promotion to Tier 2 and these changes look correct to me but the Infra team needs to sign off on the addition to CI.

[pietroalbini]

CI overhead should be negligible as this doesn't add a new standalone job.

@bors r+

[bors]

📌 Commit d185e0d has been approved by pietroalbini

It is now in the queue for this repository.

[bors]

⌛ Testing commit d185e0d with merge b8b376a...

[bors]

☀️ Test successful - checks-actions
Approved by: pietroalbini
Pushing b8b376a to master...

[heiher]

@rustbot label: +relnotes

[rust-timer]

Finished benchmarking commit (b8b376a): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	2.7%	[2.7%, 2.7%]	1
Regressions ❌ (secondary)	2.9%	[2.9%, 2.9%]	1
Improvements ✅ (primary)	-0.9%	[-0.9%, -0.9%]	1
Improvements ✅ (secondary)	-2.6%	[-2.6%, -2.6%]	1
All ❌✅ (primary)	0.9%	[-0.9%, 2.7%]	2

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.4%	[2.1%, 3.0%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 632.26s -> 631.081s (-0.19%)
Artifact size: 317.36 MiB -> 317.36 MiB (0.00%)

[xen0n]

Looks like this PR narrowly missed the beta promotion? Do we still want to stuff it into beta?

[cuviper]

It did not miss -- it merged before the version bump in #116302, so it was still auto-added to milestone 1.74.0.

But generally, no, we would not do a beta backport for a feature like this, only for high-impact bugs. The point of having frequent releases is that it should not be a big deal to wait for the next one.

[xen0n]

It did not miss -- it merged before the version bump in #116302, so it was still auto-added to milestone 1.74.0.

But generally, no, we would not do a beta backport for a feature like this, only for high-impact bugs. The point of having frequent releases is that it should not be a big deal to wait for the next one.

Thanks for the explanation! I checked the beta branch previously but didn't see this commit, hence the question. (I'd agree with waiting for the next release if the change actually missed 1.74.0, though.)