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]>.

[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

[workingjubilee]

cool, this looks reasonable, have to doublecheck if I need to check about target features with someone first before approving this, I think

[madhav-madhusoodanan]

cool, this looks reasonable, have to doublecheck if I need to check about target features with someone first before approving this, I think

Got it 😊

[bors]

☔ The latest upstream changes (presumably #140633) made this pull request unmergeable. Please resolve the merge conflicts.

[workingjubilee]

Ah found the documentation again, and I do not need to consult anyone for this feature. Yay. Rebase? and I'll get it this time.

[rustbot]

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[madhav-madhusoodanan]

Just rebased this branch and I noticed a bunch of changes to Cargo.lock.
Would it be a concern?

[sayantn]

Cargo.lock shouldn't have been modified, might just be a mistake from git. You probably have to revert it

[workingjubilee]

There should not need to be any Cargo.lock changes as part of this PR.

[workingjubilee]

Thank you! Should be good to go.

@bors r+ rollup

[bors]

📌 Commit c32dc2d has been approved by workingjubilee

It is now in the queue for this repository.