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

121–130 of 169 posts

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

#121

Post by phendrenad2 »

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.

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

#122

Post by arthur2e5 »

josefx wrote: post #80
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'…

> In the past, people have dismissed such concerns The problem is GCC made these concerns completely irrelevant. You wanted refactoring support for C or C++? Either build it on clang or get screamed at by RMS for leaking GCC internals when text base search and replace was enough for him in the early 80s. The simple fact is that there is no GNU based alternative to clang/llvm.

The “good” news on this front is that RMS has been allegedly removed from GCC’s steering committee as a side-effect of the flames of April. Emphasis on “alleged”, since some heavyweights say he was never there to begin with.

https://lwn.net/Articles/853230

Somewhere down the thread there are questions about AST, I think.

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

#123

Post by phendrenad2 »

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'…

Yes, this is a good reason for people to think twice about using non-copyleft. However, if they choose non-copyleft anyway, it's a bit presumptuous to then say the authors are stupid or misled to choose it.

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

#125

Post by pjmlp »

belgesel wrote: post #89
account42 wrote: post #57

Earlier quoted context omitted.

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.

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.

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

#126

Post by mshockwave »

floatboth wrote: post #55
ytch wrote: post #19

Earlier quoted context omitted.

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

that is for the simpler optimization. A more complicate optimization algorithm can generate quite different code depending on the inputs. So you might need many different input codes to fully explore the internal, similar to the problem facing by fuzzing and/or symbolic execution.

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

#127

Post by chaos_emergent »

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

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

#128

Post by slavik81 »

physicsguy wrote: post #31
killingtime74 wrote: post #4

Anyone actually use Intel compilers

Yeah, I used in my last job (commercial CFD code), and it was widely used by others in our sector. It's nice if you need to support Windows/Linux as well as brings for e.g. MPI, etc. and compiling scietnfic libs like FFTW on Windows is a PITA, so using MKL which comes bundled with it is very easy.

What makes compiling FFTW on Windows so troublesome? That's currently on my to-do list.

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

#130

Post by mshockwave »

zetalyrae wrote: post #12
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…

>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? I assumed the icc secret sauce was in the backend: deep knowledge of how each and every single operation is implemented in every uarch. Maybe they've written their own x86 backend for LLVM, and are using the rest of LLVM for IR->IR transformations and vectorization?

Exactly, many comments here are saying the difference is in LLVM IR ("middle-end") optimizations but IMHO more secrets are hidden in the backend. For example the latency of different instructions (and their operands) which has huge impact on the overall scheduling.
Post reply on HN