Arm Working On Function Multi-Versioning For GCC

[phoronix]

Phoronix: Arm Working On Function Multi-Versioning For GCC

A feature supported by the GNU Compiler Collection (GCC) that sadly isn't used more often is function multi-versioning (FMV) for supporting multiple versions of a function with the given function selected based upon the target processor in use. GCC FMV on x86_64 allows for different functions to be used whether supporting SSE4.2, AVX, or even a particular CPU micro-architecture. Arm is finally working on GCC function multi-versioning support for AArch64...

https://www.phoronix.com/scan.php?page=news_item&px=Arm-GCC-Function-Multi-Ver

[carewolf]

Neat. While there was traditionally no use for that feature on ARM, we have needed that for a while for Android, and is going to need it more when Apple adds new instructions the their desktop CPUs.

[hamishmb]

Yeah, anything that improves compatibility (or ease of use) or Linux on different platforms is a win for sure.

[arQon]

Neat. While there was traditionally no use for that feature on ARM

Huh?! ARM has had enormous use for it since at least the v6->hf transition.

[carewolf]

Huh?! ARM has had enormous use for it since at least the v6->hf transition.

Those archs do not have ABI compatibility so they can not be mixed at a function level this easily. Plus typically you knew the architecture you were compiling for when targetting embedded platforms, you only need runtime function version switching when targeting a platform that exists across multiple different ARM chips.

[arQon]

Plus typically you knew the architecture you were compiling for when targetting embedded platforms, you only need runtime function version switching when targeting a platform that exists across multiple different ARM chips.

I'm plenty familiar with the concept of compiling for a specific arch across various ARM chips, thanks.

If you wanted to ship a "universal" binary on ARM though, especially for a library, this would have been a useful capability. I agree it's much less so if you *have* all the source and don't *need* the capability, but that doesn't mean it has no value to anyone.

> Those archs do not have ABI compatibility

Actually, they do. It's just that it wasn't everything it should have been. https://wiki.debian.org/ArmHardFloatPort has a decent overview.

[carewolf]

I'm plenty familiar with the concept of compiling for a specific arch across various ARM chips, thanks.

If you wanted to ship a "universal" binary on ARM though, especially for a library, this would have been a useful capability. I agree it's much less so if you *have* all the source and don't *need* the capability, but that doesn't mean it has no value to anyone.

> Those archs do not have ABI compatibility

Actually, they do. It's just that it wasn't everything it should have been. https://wiki.debian.org/ArmHardFloatPort has a decent overview.

That documentation uses the same definition I did, where armhf is a minimum of armv7 plus thumb2 and VFP support. You were talking about armv6, which would have had a different ABI, being one of any combination of EABI/OABI, hard-float/soft-float, and endianness. It is quite possible one of those combos were also known as armhf back in the day, but it isn't the armhf you linked to, and as far as I know armhf assuming armv7, VFP and thumb2, was the first stable ABI we ever targeted for ARM, it was a huge mess before then.

[arQon]

as far as I know armhf assuming armv7, VFP and thumb2, was the first stable ABI we ever targeted for ARM, it was a huge mess before then.

Yes, it's always been a mess: we can certainly agree on that part.

I don't remember the details of builds from a decade ago (other than that v6 existed, didn't have an FPU, and we had to run on it) but TBH I don't really care about them when I'm not being paid to. You seem married to your position, so let's just assume you're right and move on.

v6 did at least give me an excuse to flex some Bresenham-inspired braincells for the first time in ages, so parts of that project were a lot of fun at times.