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

51–60 of 169 posts

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

#51

Post by floatboth »

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!

Copyleft licenses have no way of forcing anyone to follow upstreams more closely.

Android is a great example. Typical Qualcomm/Mediatek/etc. behavior: take a "stable" kernel, stuff it with custom undocumented drivers and junk, be stuck on that version forever. The only thing the GPL changes is the vendor posts a source dump of dubious usefulness in some obscure section of their website.

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

#52

Post by riffraff »

pjmlp wrote: post #43
andi999 wrote: post #26

Earlier quoted context omitted.

My understanding was the llvm was made because the code basis of gcc is too complicated. Since seems to be a killer move.

That was ions ago, and if not for anything else, Linux kernel will keep GCC around. Azure Sphere OS is also GCC only, despite Microsoft's new foundled love for clang.

Why would the Linux kernel keep GCC around?

I'm fairly confident the FSF would keep it alive for a long time, but I don't see why it would be necessarily be a priority for the Linux devs to keep GCC forever.

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

#53

Post by floatboth »

volta83 wrote: post #24
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…

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…

ISPC is not stuck on LLVM 7. Only fails on 12 currently, works on 11 and earlier:

https://github.com/freebsd/freebsd-ports/blob/85cccf4f15c42d...

But hopefully that will be fixed soon.

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

#54

Post by pjmlp »

riffraff wrote: post #52
pjmlp wrote: post #43

Earlier quoted context omitted.

That was ions ago, and if not for anything else, Linux kernel will keep GCC around. Azure Sphere OS is also GCC only, despite Microsoft's new foundled love for clang.

Why would the Linux kernel keep GCC around? I'm fairly confident the FSF would keep it alive for a long time, but I don't see why it would be necessarily be a priority for the Linux devs to keep GCC forever.

Linux kernel makes use of GCC C, not ISO C, also targets hardware that LLVM doesn't support.

Android Linux kernel fork actually builds with clang, and Linux kernel is yet to accept the changes made by Google.

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

#55

Post by floatboth »

ytch wrote: post #19
pjmlp wrote: post #14

Earlier quoted context omitted.

Because not everything on icc is going to be upstreamed to clang, thanks license. It is not like clang is enjoying C++ Builder RAD abilities, PS 4 and 5 optimizations, or bitcode format used by watchOS.

Yeah, I guess LLVM is preferred mostly because license. Companies can keep their optimizations in secrets. Just like why Playststion's OS is based on BSD.

It's nearly impossible to keep optimizations secret. They are the easiest thing in the world to reverse engineer: just look at the output assembly. (And you can't exactly output obfuscated assembly because that would make the performance worse, nullifying the benefits of the optimizations.)

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

#56

Post by [deleted] »

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…

[deleted]

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

#57

Post by account42 »

pjmlp wrote: post #43
andi999 wrote: post #26

Earlier quoted context omitted.

My understanding was the llvm was made because the code basis of gcc is too complicated. Since seems to be a killer move.

That was ions ago, and if not for anything else, Linux kernel will keep GCC around. Azure Sphere OS is also GCC only, despite Microsoft's new foundled love for clang.

There is significant investment in building Linux with Clang so I wouldn't count on Linux keeping GCC relevant forever. Doubly so with the inevitable rustc requirement.

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

#58

Post by nsizx »

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.

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

#59

Post by qayxc »

floatboth wrote: post #51
varajelle wrote: post #37

Earlier quoted context omitted.

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!

Copyleft licenses have no way of forcing anyone to follow upstreams more closely. Android is a great example. Typical Qualcomm/Mediatek/etc. behavior: take a "stable" kernel, stuff it with custom undocumented drivers and junk, be stuck on that version forever. The only thing the GPL changes is the vendor posts a source dump of dubious usefulness in some obscure section of their website.

> Android is a great example. Typical Qualcomm/Mediatek/etc. behavior: take a "stable" kernel, stuff it with custom undocumented drivers and junk, be stuck on that version forever.

I don't think that's such a great example in this context.

Qualcomm, Mediatek, etc. are hardware vendors after all. Software to them is a necessary evil, not a reason d'être or complementary tool (as it is for NVIDIA and Intel). Their customers fall in the same category - smartphone manufacturers want to sell units, not keep software up-to-date.

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

#60

Post by account42 »

volta83 wrote: post #27
xamolxix wrote: post #8

Earlier quoted context omitted.

I disagree. Competition is good. Don't want to end up with every C/C++ compiler being a clang skin in the same way as (almost) every browser is a chrome skin. And for what it's worth cl compiles faster for me than even clang-cl. I like having both available though.

> Don't want to end up with every C/C++ compiler being a clang skin in the same way as (almost) every browser is a chrome skin. Why not ? There is one open C++ spec, that's really hard to implement, so we have a dozen C++ compilers that are impossible to support properly because they each have their own set of different ten thousand bugs. The value of supporting all of this is really small in practice, and the cost f…

We did have one major C++ compiler on Windows (MSVC) and one major C++ compiler elsewhere (GCC) and they both stagnated in many areas before Clang came along and forced them to advance to stay competitive.
Post reply on HN