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

[phoronix]

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

Recently there was an LLVM bug report of "Worse runtime performance on Zen CPU when optimizing for Zen." Well, that's not good... Fortunately, that bug is now fixed with the latest LLVM Clang compiler code but other deficiencies in the AMD CPU optimization targeting remain...

https://www.phoronix.com/news/LLVM-Slower-With-AMD-Opts

[novideo]

As an AMD customer, it would be far more valuable to me if AMD focused their efforts only on improving upstream GCC and LLVM instead of their own proprietary LLVM fork that no Linux or other FOSS-focused OS distro will adopt. I really, really don't understand why they're developing AOCC when they can't even get upstream GCC/LLVM right. Wouldn't it be more beneficial from the business perspective as well if their optimizations reached a wider user? If they want to have some AMD-specific features that aren't suitable for upstream, can't they make AOCC a GCC and/or LLVM patchset that's still FOSS so that it reaches a much wider user base?

Tangentially, this is also why I still maintain that as good as LLVM may be from a technical perspective, its non-copyleft license is a disaster...

[kylew77]

Kinda surprised a bug like this would take so long to find, but from my compilers class in college I learned compilers are one fancy piece of software that is over my head! Back when I was experimenting with Gentoo I compiled everything mach=native. Surprised that this would take this long to find out since I'm sure many run Gentoo on ZEN class hardware!

[dragorth]

As an AMD customer, it would be far more valuable to me if AMD focused their efforts only on improving upstream GCC and LLVM instead of their own proprietary LLVM fork that no Linux or other FOSS-focused OS distro will adopt. I really, really don't understand why they're developing AOCC when they can't even get upstream GCC/LLVM right. Wouldn't it be more beneficial from the business perspective as well if their optimizations reached a wider user? If they want to have some AMD-specific features that aren't suitable for upstream, can't they make AOCC a GCC and/or LLVM patchset that's still FOSS so that it reaches a much wider user base?

Tangentially, this is also why I still maintain that as good as LLVM may be from a technical perspective, its non-copyleft license is a disaster...

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.

[edxposed]

If LLVM adopts GPL license, it's just another cathedral, a war between Christians and Islamists.

[FireBurn]

I've had quite a lot of issues with Clang 18.1 especially when compiling with -march=native

[brad0]

If LLVM adopts GPL license, it's just another cathedral, a war between Christians and Islamists.

That would never happen.

[brad0]

What a ridiculously clickbaity title and "article" this is.

[lowflyer]

It's easy to say "AMD should do more". On a more conspiratory note I could as well claim that "Intel is behind all of this".

But the real problem is all of you guys. Yes. I accuse the whole community. There are simply way too many Intel CPU's in all your boxes. It's easy to be ignorant if you're not affected.

[ms178]

It's easy to say "AMD should do more". On a more conspiratory note I could as well claim that "Intel is behind all of this".

But the real problem is all of you guys.

Are you serious? The days of Intel intentionally manipulating compilers and libraries to nerf AMD's performance are long gone. It is on AMD to provide great software support for their CPUs and not on Intel users to find and fix bugs for AMD CPUs. The gaming-centric CPU reviews are also misleading in a sense as even modern AMD CPU's lack some hardware features that are important if you want to optimize your software beyond the usual defaults (e.g. up to and including Zen 3, AMD didn't support LBR which is important for PGO/BOLT these days). And their compiler tuning is bad according to this story. Issues like the one reported here are the reason why I still use a mature Intel platform that happens to be the default target for x86-64-v3 (Haswell). And great software support matters, I therefore support the notion that AMD's upstream toolchain efforts (GCC, LLVM, Glibc etc.) should be improved further.