Announcement

Collapse
No announcement yet.

LLVM Dealing With Slower Performance On AMD CPUs When Targeting AMD Zen Optimizations

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

  • #11
    Having their own fork of the compiler tool chain enables faster development. Any benefits could be upstreamed - hopefully they do.

    Comment


    • #12
      Originally posted by dragorth View Post

      The biggest reason for AMD keeping their own fork of LLVM around is control and support. The largest buyers of AMD hardware is Business, and this is especially true of Server Hardware since Zen and Epyc came along. And businesses like to be able to have a supported compiler, somewhere they can go back to and demand a fix now.

      And when I mean business, I don't mean the end user buying it, I mean the Dell's of the world, that make the hardware platforms, the UEFI/BIOS, the GPU vendors.

      They demand crazy things that make having your own compiler stack that you specifically tailor to your customers a viable necessity.

      Even if AMD didn't distribute their AOCC, it would still exist in house for these and many other reasons. The good news is AMD does release it.
      Do you have a list of businesses and software compiled with AOCC to support your claims?

      AOCC always produces worse and slower code than gcc or clang. People try AOCC and never use this trash again.

      AOCC exists for AMD to not have to wait on gcc and clang support for its new CPUs.
      Last edited by max0x7ba; 21 May 2024, 02:34 PM.

      Comment


      • #13
        Originally posted by max0x7ba View Post

        Do you have a list of businesses and software compiled with AOCC to support your claims?

        AOCC always produces worse and slower code than gcc or clang. People try AOCC and never use this trash again.

        AOCC exists for AMD to not have to wait on gcc and clang support for its new CPUs.
        How do you think bring up happens for these new platforms? I listed those OEMs for a reason.

        Comment


        • #14
          Originally posted by dragorth View Post

          How do you think bring up happens for these new platforms? I listed those OEMs for a reason.
          What exact software do those compile with AOCC, which they cannot compile with available compilers?

          You compile your UEFI/BIOS for generic `-march=x86-64-v4` and call it a day.

          It may compile `memset` into older avx2 stores than the newer SIMD available on the CPU, but does it matter for BIOS which runs only at start-up?

          Comment


          • #15
            Originally posted by max0x7ba View Post

            What exact software do those compile with AOCC, which they cannot compile with available compilers?

            You compile your UEFI/BIOS for generic `-march=x86-64-v4` and call it a day.

            It may compile `memset` into older avx2 stores than the newer SIMD available on the CPU, but does it matter for BIOS which runs only at start-up?
            It matters when you are the one in charge of making the CPU boot in the first place, making sure the first bit of CPU microcode is uploaded, and GCC and LLVM don't have access to the CPU when you are building it and when you are troubleshooting your debug boards before the chips are announced.

            When you are testing new standards before they are locked in you need the right tool, one that actually knows the quirks of your barely working hardware.

            GCC and LLVM are great for standards that are locked in and productized, but before that, you need a to have more access.

            AMD could have made theirs based on GCC or whatever, but they would have it. Intel used to have their own as well.

            Comment


            • #16
              Originally posted by dragorth View Post

              It matters when you are the one in charge of making the CPU boot in the first place, making sure the first bit of CPU microcode is uploaded, and GCC and LLVM don't have access to the CPU when you are building it and when you are troubleshooting your debug boards before the chips are announced.

              When you are testing new standards before they are locked in you need the right tool, one that actually knows the quirks of your barely working hardware.

              GCC and LLVM are great for standards that are locked in and productized, but before that, you need a to have more access.

              AMD could have made theirs based on GCC or whatever, but they would have it. Intel used to have their own as well.
              From your comments it is not clear who uses AOCC to build what.

              Would you be so kind and provide a textbook-style case study: what company uses AOCC to build exactly what; and why no existing toolchain for the same CPU instruction set is sufficient for that purpose, exactly, please?



              Comment

              Working...
              X