Adding target attribute for function.

[kito-cheng]

After adding mapping symbol and .option arch, finally we have all necessary components of function multi-versioning.

This proposal has add a new funciton attribte: target attribte for compile a funciton with specify extension, pipeline model or cost model, could be used as simple* function multi-versioning.

*: Simple is compare to target_clones in x86 and target_version in AArch64, and also require user to dispatch that right.

It similar to AArch64's target attribte: https://gcc.gnu.org/onlinedocs/gcc/AArch64-Function-Attributes.html

This attribte won't change the function name mangling, and also require do not update Tag_RISCV_arch attribte.

Ref:

• https://maskray.me/blog/2023-02-05-function-multi-versioning

---

NOTE: This PR will not be merged until we have PoC AND GNU/LLVM community reach consensus NOTE: We don't have PoC for either GCC and clang yet,

[kito-cheng]

cc @asb @luismarques @maskray @jrtc27 @topperc @preames @palmer-dabbelt @vineetgarc

[kito-cheng]

PoC for LLVM: https://reviews.llvm.org/D151730

[palmer-dabbelt]

Is this meant to plumb into function multi versioning as well, or just control single-versioned functions? Either way Jeff might have something to say, not sure what his github ID is though...

[kito-cheng]

This is for single-versioned functions or you can called manually multi-versioning since it must be gated by user, and multi-versioning will based on this and then extend, might be target_clone and/or target_version, e.g. target_clone ("same-syntax-as-target-attr1", "same-syntax-as-target-attr2")

[kito-cheng]

Either way Jeff might have something to say, not sure what his github ID is though...

Should be this one @JeffreyALaw

[kito-cheng]

Changes:

• Drop the '-' op due to lack of clear definition.

[kito-cheng]

Changes:

• Fix the syntax to allow more than two ATTR.
• Speicfy the interactions among arch, tune, and cpu.
• Describe the behavior if same ATTR appear more than once.
• Mention compiler should always generate the function even the attribute compiler will generate same code without attribute.

TODO:

• We may specify the inlining rule like other target https://gcc.gnu.org/onlinedocs/gcc/AArch64-Function-Attributes.html#Inlining-rules

[kito-cheng]

Changes:

• Clarify the interaction between attribute and option, e.g. -march and arch=.
• Improving wording and fix several grammatical issue

[kito-cheng]

Minor tweaks

• Drop disable a set of features or extensions, we don't have syntax to drop now.
• Tweak description for arch=: describe two different cases of arch= clearly.
• Drop last sentence, that will happened on multi-version funciton but not happen in target attribute.

[kito-cheng]

cc @maskray, who might interested on this topic

[cmuellner]

I've reached out to the sig-toolchains list with a request for review with the intend to merge this PR in two weeks.

The planned timeline is as follows:

Oct 13: Send request for review to sig-toolchains list Oct 27: End of review period (PR will be merged if there are no outstanding issues)

[preames]

To provide a bit more context on the in person conversation last week...

@kito-cheng and I sat down at the LLVM developers meeting to go over the then current draft text and identified a couple of last minor issues. I provided a verbal LGTM at that point, subject to the changes identified being made. @topperc and @maskray joined in for the last part of our spoken conversation just before I ran off to a talk. I'm unclear if all their concerns were resolved. I think they were, but I don't want to speak for them.

One point I want to call out in our discussion is that we tentatively decided not to implement function multi-version semantics for target in C++. (On X86, C and C++ semantics for this attribute differ with C++ providing a form of a overloading based on attribute.) We're going to leave that case to target_clone and keep the plain target attribute simpler. This does result in a difference with other architectures, but given aarch64 and x64 already seem to differ significantly on the semantics assigned to this attribute, that seemed acceptable.

[kito-cheng]

Minor revise:

• Add link for mapping symobl.
• File scope -> translation unit scope

[kito-cheng]

Reach consensus on error when multiple __attribute__((target)) and duplicated value (same type of attribute) at RISC-V LLVM sync meeting.

Action item: Kito will discuss in next RISC-V GCC sync meeting, make sure everyone is happy with that.

[MaskRay]

For x86, GCC in C++ mode (but not in C mode) enables function multi-versioning for the following setup:

__attribute__((target("default"))) int foo(void) { return 0; }
__attribute__((target("sse4.2"))) int foo(void) { return 1; }

I think this is confusing. For RISC-V I think it makes sense not to enable function multi-versioning or make __attribute__((target("sse4.2"))) part of the mangling.

[kito-cheng]

Changes:

• Compiler emit error instead of take latest one if same type of attribute specified more thane once, also same behavior for target attribute specified twice.
• Explicitly declare target attribute not support multi-versioning.

[kito-cheng]

Also reach consensus at RISC-V GNU community :)

@maskray let me know if the spec is look good to you.

[preames]

This has been under active discussion for months, and recently went through the 2 week comment period without significant comment. I think it's time to move forward here.

[kito-cheng]

Let moving forward, thanks everyone :)