Added support for apxf target feature

[madhav-madhusoodanan]

Context

1. Added the apxf target feature, which is dependent upon the LLVM features egpr, push2pop2, ppx, ndd, ccmp, nf, cf and zu.
2. Converted dependencies of LLVMFeature from an Option to a SmallVec to support multiple dependencies.

Associated Issue

• Tracking Issue for APX target feature #139284

cc: @sayantn

[rustbot]

r? @SparrowLii

rustbot has assigned @SparrowLii.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[madhav-madhusoodanan]

I would be grateful if a perf-run could be initiated for this PR.

I think I do not have sufficient privileges for initiating it.

[sayantn]

Also, do run ./x check tidy before you push, it ensures that CI won't fail right away due to tidy checks

[SparrowLii]

Sry I'm not familar with llvm so
r? codegen

[madhav-madhusoodanan]

Have updated dependencies from a SmallVec<[_, 10]> to a SmallVec<[_, 1]>.

[Kobzol]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 99b5a86 with merge e3d0b57...

[bors]

☀️ Try build successful - checks-actions
Build commit: e3d0b57 (e3d0b57c7d61bdc8834ac5fd480f14f9182751ba)

[rust-timer]

Finished benchmarking commit (e3d0b57): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.7%	[0.5%, 0.9%]	2
Improvements ✅ (primary)	-0.6%	[-1.2%, -0.2%]	3
Improvements ✅ (secondary)	-0.3%	[-0.6%, -0.2%]	17
All ❌✅ (primary)	-0.6%	[-1.2%, -0.2%]	3

Max RSS (memory usage)

Results (secondary -0.2%)

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)	3.2%	[2.8%, 3.5%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-6.9%	[-6.9%, -6.9%]	1
All ❌✅ (primary)	-	-	0

Cycles

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

Binary size

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

Bootstrap: 780.245s -> 779.828s (-0.05%)
Artifact size: 366.19 MiB -> 366.21 MiB (0.01%)

[sayantn]

You also have to add apxf to tests/ui/check-cfg/target_feature.stderr

[sayantn]

@chorman0773 should inline-asm-use-gpr32 be added here? Or are we completely going to reg_ext for gpr32?

[chorman0773]

No, leave it off. There are enough instructions that you can't necessarily use an egpr.

[madhav-madhusoodanan]

No, leave it off. There are enough instructions that you can't necessarily use an egpr.

Just to clarify, llvm_utils by default wraps the target string into an LLVMFeature, so I'm guessing we wouldn't explicitly need to add inline-asm-use-gpr32 right? (incase a developer needs to use the feature, that is)

[sayantn]

iiuc, the reason apxf should not imply inline-asm-use-gpr32 is that the new r16-31 registers don't support evex or vex encoded instructions, only rex2 encoding. So they can't be used as regular registers. If inline-asm-use-gpr32 is enabled, llvm might assign a egpr in a reg class, which will generate invalid asm. Target features should not create unsoundess (although they have the potential to do so 😆). There are llvm constraints that we can use to allow users to use gpr32 without activating the i-a-u-g32 tag, so this is not a loss. @chorman0773 is working on a new reg class that will do exactly this, so no need for i-a-u-g32 here