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

141–150 of 169 posts

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

#141

Post by dhosek »

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.

This is part of why I specified “on my computer.” I used to use university/work systems and whether it was paid for separately or as part of the OS, I generally had a variety of compilers available to me. My personal favorite oddity was that IBM had two different Pascal compilers for VM/CMS. One was called Pascal/VS and the other VS/Pascal. One was slightly more capable than the other, but I don't remember which it was or what, precisely the difference was. It never came up in compiling TeX and its related software. I do remember the long process of installing PL/I on the UIC mainframe back in the 80s though.

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

#142

Post by dhosek »

dhosek wrote: post #141
trasz wrote: post #87

Earlier quoted context omitted.

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

This is part of why I specified “on my computer.” I used to use university/work systems and whether it was paid for separately or as part of the OS, I generally had a variety of compilers available to me. My personal favorite oddity was that IBM had two different Pascal compilers for VM/CMS. One was called Pascal/VS and the other VS/Pascal. One was slightly more capable than the other, but I don't remember which it w…

I'd add that in the early 90s, Linux was very much a fringe OS. I had contemplated running FreeBSD (or was it BSDFree?), but as I only had one computer and getting a second seemed an unimaginable expense, I never did so (I don't think virtual machines on x86 were a viable thing yet either).

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

#143

Post by rincebrain »

pjmlp wrote: post #125
belgesel wrote: post #89

Earlier quoted context omitted.

Isn't that the other way around? I thought clang was trying to support all gcc extensions to be able to build Linux kernel. I would rather see both of these compilers to stay competitive to push themselves higher.

clang already builds Linux kernel on Mountain View dungeons, and it has been doing that for a couple of years now. Those changes just don't get to upstream.

That's...not true?

https://www.kernel.org/doc/html/latest/kbuild/llvm.html

I could be missing something, but I don't see any suggestion that you need a specific forked tree with patches to build with LLVM, and I've seen people filing bugs about using LLVM sanitizers to build the vanilla tree, so I don't think the expectation is that you need to apply a huge out of tree patchset for this to work any more?

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

#144

Post by topspin »

chaos_emergent wrote: post #127
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…

What’s even stranger is that as a 26 year old this is my first time hearing that compilers used to be paid for :) what a great indication of the FOSS movement’s success

"used to be"

They still are in many cases. Proprietary compilers for embedded devices (MCUs, FPGAs, etc.) are still commonplace. The license for the full Intel compiler suite discussed here isn't free either.

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

#145

Post by zamadatix »

phendrenad2 wrote: post #121
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…

Everyone says software monocultures are bad, without evidence. In fact, there seems to be evidence against this: the Linux kernel.

The Linux kernel isn't a monoculture yet. For example there is no indication Apple or the BSDs are going to stop developing their kernels nor is there indication Windows is dropping NT and most anything can/is easily moved between them (particularly the *NIX kernels) still. That doesn't mean there are certain places the only choice is the Linux kernel but that alone isn't enough to make it a monoculture in this sense of nearing domination of the space.

Browsers are the most oft cited example of monoculture issues be it the old days with IE or the new days with Chrome, I'm surprised you haven't run across comments on that one over the years.

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

#146

Post by Thiez »

pjmlp wrote: post #111
ip26 wrote: post #93

Earlier quoted context omitted.

Why is this worse than totally proprietary & closed source icc?

Leeching on the work that Johnny/Jane dev might have contributed to LLVM as part of their PhD thesis in compiler optimisations.

If Johnny/Jane didn't want their contributions to be used like that they could have licensed them differently though, or contributed to gcc instead. Of course llvm wouldn't accept their contributions if they were licensed under, say, the AGPL. But presumably getting their changes upstreamed is not a condition for completing their thesis, so it's their choice. As a PHD student they are hopefully capable of reading and understanding these licenses (to the degree that someone who hasn't studied law can understand such things).

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

#147

Post by pjmlp »

Thiez wrote: post #146
pjmlp wrote: post #111

Earlier quoted context omitted.

Leeching on the work that Johnny/Jane dev might have contributed to LLVM as part of their PhD thesis in compiler optimisations.

If Johnny/Jane didn't want their contributions to be used like that they could have licensed them differently though, or contributed to gcc instead. Of course llvm wouldn't accept their contributions if they were licensed under, say, the AGPL. But presumably getting their changes upstreamed is not a condition for completing their thesis, so it's their choice. As a PHD student they are hopefully capable of reading and…

True, except in this fictional story maybe the condition was set by the professor, university department and not a free option of the respective student that now sees his work being abused by a mega corp too cheap to contribute back.

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

#148

Post by pjmlp »

rincebrain wrote: post #143
pjmlp wrote: post #125

Earlier quoted context omitted.

clang already builds Linux kernel on Mountain View dungeons, and it has been doing that for a couple of years now. Those changes just don't get to upstream.

That's...not true? https://www.kernel.org/doc/html/latest/kbuild/llvm.html I could be missing something, but I don't see any suggestion that you need a specific forked tree with patches to build with LLVM, and I've seen people filing bugs about using LLVM sanitizers to build the vanilla tree, so I don't think the expectation is that you need to apply a huge out of tree patchset for this to work any more?

I follow Android, not Linux itself.

My latest update was that not all patches were accepted upstream, or Google didn't care about upstreaming them, whatever.

There are some Linux Plumbers talks, or from Linaro, about this a years back.

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

#149

Post by pengaru »

UncleOxidant wrote: post #133
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 never understood why Intel sold their compilers anyway. The revenue from compilers must be a tiny drop in Intel's revenue bucket. And if you're fine tuning your compiler to work best with your architecture it seems like you'd want to be giving that away to further promote sales of your chips. Now that they're using LLVM they should just upstream everything to the LLVM project and quit selling icc.

I agree they should upstream everything to gcc/clang to make their processors smoke the competition, but always assumed icc being a paid-for product came with additional support and access to Intel's expertise in using their tools and processors.

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

#150

Post by marcos100 »

ch_123 wrote: post #72
marcos100 wrote: post #38

Earlier quoted context omitted.

Wasn't LLVM reinventing the wheel at the time? They could just collaborate to GCC.

They wanted to, but RMS wasn't interested at that time: https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00... I have also been told by more than one person that does professional compiler development that GCC's codebase is very difficult to work with. At least some commentary I've read suggests that this was a deliberate choice on the part of the GNU project.

Sure, I'm not denying any problems with the GCC codebase and/or how RMS handles GNU software.

Just pointing that reinventing the wheel is not necessarily a bad thing or a waste of time.

Post reply on HN