Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel C/C++ compilers complete adoption of LLVM

software.intel.com

Post reply on HN
Print view View original

101–110 of 169 posts

Re: Intel C/C++ compilers complete adoption of LLVM

#101

Post by atty »

jasonhansel wrote: post #79

This is exactly why I've been concerned about LLVM's use of a non-copyleft license: unlike with GCC, vendors can create their own proprietary extensions and optimizations without contributing them back to the community. (In the past, people have dismissed such concerns, saying that it would be impractical for anyone to actually do such a thing. But this project by Intel shows that it isn't just possible--in fact, it'…

I think it is relevant to point out that Intel’s compiler team would almost certainly never have chosen LLVM in the first place, if it forced them to release whatever secret sauce is giving them the performance increases we see in those performance plots. So it’s not so much a “look at how much LLVM is missing out on by not using copyleft”, it’s more of a “LLVM has gotten some benefit from Intel adopting their tech and putting some of their work back into the open source project”.

Sure, I’d love for Intel to upstream every optimization they make, but I don’t see that as necessary or even good business sense for either Intel or LLVM.

Re: Intel C/C++ compilers complete adoption of LLVM

#102

Post by ekiwi »

flyinghamster wrote: post #49

AMD's own optimizing compiler is also LLVM-based. So, we now can wind up with the situation of both compilers adding spiffy optimizations and then never upstreaming them. It's less of a problem if the two of them don't decide to add their own proprietary "extensions" to the language. That may be something to look out for going forward.

> if the two of them don't decide to add their own proprietary "extensions" to the language.

icc has always had its own dialect of C++, which in practice means that there is "C++" code that only compiles on icc but is rejected by clang++ and g++. With Intel switching to the clang frontend, I would hope that their interpretation of C++ will become more, not less, standard conform.

Re: Intel C/C++ compilers complete adoption of LLVM

#103

Post by malkia »

nly wrote: post #22
andi999 wrote: post #11

Earlier quoted context omitted.

Yes, I think though gcc will go first.

GCC will never completely die. MS though have been moving in the Clang/LLVM direction for years, so I would have zero surprise if VC++ was completely removed tomorrow. My feeling is, as soon as they can be sure they have achieved 100% binary compatibility, MS will jump. The optimizers in VC++ are light years behind, and companies like Apple are embarrassing them on the compatibility front with things like Rosetta 2 (…

There are probably lots of MSVC specific extension (COM, C++/CLR, some pragma file_hash-ing https://www.reddit.com/r/cpp/comments/ep77ey/cl_ph_or_pragma... that would neeed to get ported) - just some examples that come to mind.

Re: Intel C/C++ compilers complete adoption of LLVM

#104

Post by beached_whale »

varajelle wrote: post #37
volta83 wrote: post #24

Earlier quoted context omitted.

What that sentence actually means is "we don't want to help our competition (AMD, NVIDIA) but we don't want to re-implement the wheel". The API and fundamental part of LLVM is its IR, LLVM-IR, which is where most optimizations happen. From this point-of-view, LLVM is a "platform", and an extremely brittle one: every release has breaking changes to the IR, the IR is constantly evolved to support new hardware and new o…

Same thing with C++Builder whose last version from this year is still based on LLVM 5, I think. Even Apple's clang is behind LLVM upstream if I'm not mistaken. The joy of permissive licenses!

Apple's is up to 6mo old at release, so currently around clang10/11. Every so often it gets 2 releases behind as they are both on 6mo cycles. It's not bad really and currently Clang 12 brings few compelling reasons to upgrade. The issue will be Clang 13 is supposed to have a bunch of C++20 things, I think, and it will also be one of those ones that has a long time before Apple releases their next one.

Re: Intel C/C++ compilers complete adoption of LLVM

#105

Post by kevin_thibedeau »

fsloth wrote: post #25
MauranKilom wrote: post #18

Earlier quoted context omitted.

> Also: if icc is going to go with LLVM as a backend, then what is the point of using icc at all? Why not just use clang? From the blog post: " Not all our optimization techniques get upstreamed—sometimes because they are too new, sometimes because they are very specific for Intel architecture. This is to be expected and is consistent with other compilers that have adopted LLVM. " I don't see any good technical reaso…

"I get it, there's no money to be made in just implementing all your optimizations in clang directly." Sounds really shortsighted. I would imagine revenue from Intel dev tools is a rounding error in Intel's complete revenue stream?

It's a marketing tool to make their competitors look bad. That it is sometimes useful is a secondary side effect.

Re: Intel C/C++ compilers complete adoption of LLVM

#106

Post by [deleted] »

fay59 wrote: post #100
OskarS wrote: post #9

I'm not sure I love this. I mean, LLVM is awesome and everthing, but software monocultures are pretty bad. It's not like the situation is dire yet (given that there are also GCC and MSVC), but you can imagine a situation in a couple of years when Microsoft goes "yeah, we're also gonna go with LLVM now" and also GCC starting to fade away. It's a bit concerning. Also: if icc is going to go with LLVM as a backend, then…

I like to think of LLVM as a piece of infrastructure, like neutral fiber wiring that any ISP is allowed to use. From that perspective, I’m a lot less concerned about having few options that I am about browsers. Although the diversity of C/C++ compilers is descending, the number of compiler backends in general is still pretty high (Go, .NET compilers & runtimes, Java compilers & runtimes, JS engines, etc), and LLVM ca…

[deleted]

Re: Intel C/C++ compilers complete adoption of LLVM

#107

Post by GuB-42 »

nsizx wrote: post #58
OskarS wrote: post #9

I'm not sure I love this. I mean, LLVM is awesome and everthing, but software monocultures are pretty bad. It's not like the situation is dire yet (given that there are also GCC and MSVC), but you can imagine a situation in a couple of years when Microsoft goes "yeah, we're also gonna go with LLVM now" and also GCC starting to fade away. It's a bit concerning. Also: if icc is going to go with LLVM as a backend, then…

GCC still has time to relicence if they want to survive.

Why would GCC relicense? It exists for the license, not the other way around.

The entire point of GCC and the GNU project is to have an entire system with only free software, and the way to achieve that is not by allowing in more proprietary code.

Let GCC die if it has to die, but changing the license would make it meaningless.

Re: Intel C/C++ compilers complete adoption of LLVM

#108

Post by logicchains »

volta83 wrote: post #77
lenkite wrote: post #47

Earlier quoted context omitted.

Clang is lagging behind in C++ 20 support while MSVC is miles ahead. LLVM is also getting slower and slower every release.

So? I don't see how focusing the available manpower on one implementation instead of splitting it over 10 different implementations would make this worse. I do see how it would make this much better. What one implementation lacks, another implementation provides. This is a weakness of the current ecosystem. Most software projects restrict themselves to the minimum common denominator, and splitting manpower across com…

You sound like you haven't worked with many BigCo projects. Clang is turning into an "enterprise" junkyard due to too many cooks spoiling the broth, crumbling so much under the weight of its own complexity that 2022 is almost here and support for C++20 still isn't anywhere near complete (unlike GCC). The more parties that get involved, the worse the code will get. Clang already has more people working on it than MSVC, yet MSVC is iterating faster; this suggests a fundamental problem with the architecture or development processes of Clang, which is not something that will be fixed by more hands on deck (remember the mythical man-month).

Re: Intel C/C++ compilers complete adoption of LLVM

#109

Post by TillE »

malkia wrote: post #103
nly wrote: post #22

Earlier quoted context omitted.

GCC will never completely die. MS though have been moving in the Clang/LLVM direction for years, so I would have zero surprise if VC++ was completely removed tomorrow. My feeling is, as soon as they can be sure they have achieved 100% binary compatibility, MS will jump. The optimizers in VC++ are light years behind, and companies like Apple are embarrassing them on the compatibility front with things like Rosetta 2 (…

There are probably lots of MSVC specific extension (COM, C++/CLR, some pragma file_hash-ing https://www.reddit.com/r/cpp/comments/ep77ey/cl_ph_or_pragma... that would neeed to get ported) - just some examples that come to mind.

They could deprecate most of that stuff and let the old compiler still exist for those who need it, much like how they've been handling XP compatibility for the past several years.

But I see no signs of MSVC going away any time soon; Microsoft has a very active and capable compiler team.

Re: Intel C/C++ compilers complete adoption of LLVM

#110

Post by pjmlp »

trasz wrote: post #87
dhosek wrote: post #86

It's still a little strange to me the whole free compiler thing. I used to pay hundreds of dollars each for, first Turbo C/C++, then Borland C/C++ and Zortech C/C++. I think IBM's C/C++ for OS/2 was the first time the compiler came free with an OS that I had on my computer and I was literally shocked that it included—for free—the GUI for building GUI applications. I guess being old is what makes me perfectly fine wit…

Early Unix systems came with bundled compiler toolchain. I think it was the SunOS which unbundled it first.

Yes, and made plenty of people rush to GCC's implementation effort, which was largely ignored until that moment.
Post reply on HN