Announcement

Collapse
No announcement yet.

AMD Zen 4 Cost Table & Tuning Patches Posted For The GCC Compiler

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

  • AMD Zen 4 Cost Table & Tuning Patches Posted For The GCC Compiler

    Phoronix: AMD Zen 4 Cost Table & Tuning Patches Posted For The GCC Compiler

    Back in October AMD sent out their initial Zen 4 "znver4" enablement for the GCC compiler. That initial Zen 4 support was since merged for GCC 13 but that initial enablement carried over the cost tables from Zen 3 and didn't do much in the way of tuning but rather just flipping on the new instructions supported by the Ryzen 7000 series and EPYC 9004 series processors. Today there is finally some juicy tuning patches being sent out for GCC...

    https://www.phoronix.com/news/AMD-Ze...ble-Tuning-GCC

  • #2
    About AMD and SUSE


    Sponsors
    Platinum sponsors of openSUSE


    53863A AMD E Blk RGB.png


    and no one morew

    Gold Sponsors of openSUSE
    https://en.opensuse.org/Sponsors


    and remeber
    An Early Port Of GCC To AMD's GCN Architecture
    on 22 September 2016 at 11:40 AM EDT. 15 Comments

    While still in its early stages, there's a port in the works of the GNU Compiler Collection for AMD's GCN (Graphics Core Next) instruction set architecture.

    Longtime SUSE toolchain expert Jan Hubicka started a port of GCC to AMD GCN
    https://www.phoronix.com/news/GCC-For-AMD-GCN-Early
    as weel as
    https://gcc.gnu.org/wiki/cauldron201...GCC+to+GCN.pdf

    Comment


    • #3
      I wonder, might be feasible to just fix the x264 code to handle that edge case? Obviously it's used as an example, but it's being weighted as more than that.

      Comment


      • #4
        Originally posted by GreenReaper View Post
        I wonder, might be feasible to just fix the x264 code to handle that edge case? Obviously it's used as an example, but it's being weighted as more than that.
        Yeah, you can drop hints to let the compiler know whether a loop is big or small via __builtin_expect()1. I'm not sure how much mileage the optimizer currently gets out of those, however.

        That said, I think it's wise not to disregard x264 or hack it to be faster, because they're using it as a representative sample of much other code in the wild.

        It'd be interesting if there were an option to tell the compiler to assume un-hinted loops are big. You could use that when compiling code where the performance-critical path has been carefully annotated (or if using PGO). That could unleash lots of the more aggressive loop optimizations.

        References:
        1. https://gcc.gnu.org/onlinedocs/gcc-1...Other-Builtins

        Comment

        Working...
        X