This was breaking for us because can_use_perf_counters() in lit.local.cfg couldn't find llvm-exegesis in the first place.

amend commit message

FWIW, at Arm we decided to keep the old name mangling to minimise friction with existing code/libraries, but allow more operations with this same name-mangling. We also discussed with Red Hat and they were ok with this.

LGTM

@tmatheson -^ ?

In D141650#4064617, @fpetrogalli wrote:

In D141650#4064127, @Nuullll wrote:

In D141650#4056383, @lebedev.ri wrote:

In D141650#4055313, @Nuullll wrote:

Thanks a lot for reviewing!

@lebedev.ri

1. Do we need that parameter? Is empty <parameters> list generally ill-formed and must be diagnosed?

There's one subtle difference in AArch64 and X86 VFABI documentations about Vector Function Name Mangling: the X86 doc explicitly allows an empty parameter list while the AArch64 doc doesn't -- so I think this is why we need a parameter to let users choose whatever standard to conform. In fact, our internal implementation has to remove the diagnostic on empty parameter from tryDemangleForVFABI to make sure we're conforming the X86 VFABI.

Nitpick: would it be possible to simply ask AArch64 for clarification, what is the intended behaviour for them?

@fpetrogalli Can you please kindly provide some inputs on AArch64 VFABI? Reference commit: https://github.com/ARM-software/abi-aa/commit/8fcf3f72d7cc200c50a4b029cee295469ab46fe5

It's been a long time since I looked into this, but from a quick skimming thought the Parameter mapping rules I think the behaviour of AArch64 would be to allow empty parameters list.

If you consider a function with signature int f(void), it means that the function has no input parameters. This means that the only <P> (parameter or return value, in the notation of the specs) considered to create the vector function is the return value.

So, if targeting for example NEON, the sequence of rules for mangling the name would be:

1. MTV(P) = true (rule 3 of 4.1.1)
2. PBV(P) = true ( rule 1 of 4.1.2)
3. MAP(P) = ADVSIMD_MAP(P) (rule 2 of 4.1.3)
4. LS(P) = 4 (rule 2 of 4.2.1 - T(P) is the type of P in the specs)
5. NDS(f) = 4 (4.2.2)
6. VLEN = 2,4 (rule 2 of 4.3.1)
7. ADVSIMD_MAP(P) is a vector of VLEN elements of type T(P) (=int). -> int32x2_t and int32x4_t -> 2 vector functions can be associated to f (because NEON has 64 and 128 bit vector register views) (rule 3 of 4.3.2)

Therefore, according to the name mangling function at 4.5.1, we have 2 vector functions associated to f:

• int32x2_t _ZVGnN2_f()
• int32x4_t _ZVGnN4_f()

I hope helps clarifying a bit the current situation (unless of course I misinterpreted the specs).

I am CCing @stuij (hello mate! :) ), who I think is responsible for these bits of the compiler and the specs these days.

Notice that in the example with f I have ignored the generation of the versions that use Masking, because it seems odd to use masking for a function that have no input parameters... something that would need sorting in the specs, probably?

I meant to mark this as dropped after Tomas' comment, but searching through the codebase I don't see any tests for convert<X>to<Y>. Are those not needed at all anymore, or were they accidentally cut?

rephrasing after review comment

fix typo

I went back and forth on this for a bit. There's a review outstanding to change the mangling name for X86: https://reviews.llvm.org/D136919 to align with the C++23 std::bfloat16_t issue from above. I settled on preferring to be conservative, and not risk at some point accidentally opting an arch into a name that doesn't conform with their ABI.

simplified code some more

addressed review comments

addressed review comment

Thanks for the manual. It uses "b (2)" which resolves my question. Where does "extra range of 2048 bytes" come from?

The maximum range of a BL is 4MB. So of course the max a ThunkSection can be placed from this BL is also 4MB. At this point we could use a short Thunk which for Thumb on v4/5/6 is a maximum of 2048 bytes (our friend b (2). But this seems like an unlikely scenario as the ThunkSection would have to be placed exactly 4MB away from the call site, or at least within 2048 bytes from 4MB away to have any effect.

removed the lambdas as with the other CSSC patches

address review comment

removed lambdas, addressed review comment

In D140633#4015503, @MaskRay wrote:

On these architectures (v4, v5, and most of v6), we could replace the b.w with a Thumb b (2) instruction, but that would in an ideal situation only give us an extra range of 2048 bytes on top of the 4MB range of a BL,

Q: what is "Thumb b (2)" ?

unlambdify actions

addressed review comments

flip around .legalIf and .minScalarIf in the action definition builder

addressed review comment

spun out minScalarIf definition into it's own patch

remove changes to select-abs.mir

minor code cleanup

moved HasCSSC further up the file

addressed review comments

LGTM

edit commit message to reflect thunk renaming

change thunk names to agreed upon wording

addressed various review comments

NDS has a v5T and a v4T, not sure what the development story was for it, whether the software used v4T exclusively or the chips were programmed independently.

In D139888#3991052, @MaskRay wrote:

What are the "absolute relocations"? They usually refer to R_ARM_ABS32 and other relocation types that are represented as R_ABS in lld.

"linker" in the subject isn't useful. The directory is all about the linker implementation.

renamed commit message