Announcement

Collapse
No announcement yet.

Arm Working On Function Multi-Versioning For GCC

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • arQon
    replied
    Originally posted by carewolf View Post
    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.

    Leave a comment:


  • carewolf
    replied
    Originally posted by arQon View Post

    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.
    Last edited by carewolf; 25 July 2022, 06:00 AM.

    Leave a comment:


  • arQon
    replied
    Originally posted by carewolf View Post
    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.

    Leave a comment:


  • carewolf
    replied
    Originally posted by arQon View Post

    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.

    Leave a comment:


  • arQon
    replied
    Originally posted by carewolf View Post
    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.

    Leave a comment:


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

    Leave a comment:


  • carewolf
    replied
    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.

    Leave a comment:


  • phoronix
    started a topic Arm Working On Function Multi-Versioning For GCC

    Arm Working On Function Multi-Versioning For GCC

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

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
Working...
X