hexagon: Add HVX target features

[androm3da]

This will be used in order to emit HVX intrinsics

[rustbot]

r? @jieyouxu

rustbot has assigned @jieyouxu.
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

[jieyouxu]

@rustbot reroll

[mati865]

@rustbot reroll

[folkertdev]

r? me

[folkertdev]

These are added for use in stdarch, see rust-lang/stdarch#1999.

We've had some trouble with feature flags that influence ABI in the past (e.g. vector registers, softfloat). Do any of these features change the ABI at all? (doesn't look like it, just checking)

[androm3da]

We've had some trouble with feature flags that influence ABI in the past (e.g. vector registers, softfloat). Do any of these features change the ABI at all? (doesn't look like it, just checking)

The existing +hvx feature does impact the ABI - vector registers and pairs are used as params/retvals, but these new hvxv* subtarget features (which imply hvx) do not impact it beyond that.

Not sure if I covered the concern but I can clarify in more detail and refer to the ABI spec and the backend behavior to help cover anything I left out.

[folkertdev]

Right, that one's already in.

A different way to phrase what I'm asking: for each of these new features, if I had an object that was compiled with the feature, and one without (but it still enables implied features), and linked them together, would that cause UB?

For vector registers that is the case, because the two sides would disagree on how vector values are passed. But it sounds like hvxv* are just further extensions on top of hvx that themselves cause no such issues.

[androm3da]

Right, that one's already in.

A different way to phrase what I'm asking: for each of these new features, if I had an object that was compiled with the feature, and one without (but it still enables implied features), and linked them together, would that cause UB?

It's safe to mix object files of varying hvxv* codegen. The linker will promote the .hexagon.attributes to the highest one when merging, each one is a superset of its predecessors -- just new opcodes.

For vector registers that is the case, because the two sides would disagree on how vector values are passed. But it sounds like hvxv* are just further extensions on top of hvx that themselves cause no such issues.

Yes, exactly.

Footnote/aside - there's a clang feature that's pending that will distinguish between some of the HVX Vector types, it rejects assignments among float/integer types because of some precision loss when they're used with certain opcodes. The precision that's lost in this case is uarch state beyond the scope of the architecturally-visible vector register, so again here should be no impact to the ABI. I'll see about making a corresponding Rust feature and types when that lands in clang.

[folkertdev]

Cool, this should be good then

@bors r+

[rust-bors]

📌 Commit 8c1e51f has been approved by folkertdev

It is now in the queue for this repository.