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

[phoronix]

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-Zen4-Cost-Table-Tuning-GCC

[Peter Fodrek]

About AMD and SUSE


Sponsors
Platinum sponsors of openSUSE





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/cauldron2016?action=AttachFile&do=view&target=Porting+GCC+to+GCN.pdf

[GreenReaper]

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.

[coder]

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()¹. 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