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

91–100 of 169 posts

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

#91

Post by spookthesunset »

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 mean GCC kinda picked their path back when they made it hard to be modular. The market has spoken and looks like LLVM made the right call.

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

#92

Post by DSingularity »

phkahler wrote: post #90
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'm all for Intel helping improve LLVM, but the technical arguments for maintaining a separate commercial version don't convince me at all. This is exactly why GCC is GPL and why RMS didn't want to make it more modular. Taken to the extreme we could end up with proprietary hardware that requires a proprietary (closed) compiler even though it's built on open source. Going back to "trusting trust" things might not b…

What does “trusting trust” have to do with this? That problem is a bootstrapping problem when trying to establish a trusted base. Simple summary is: if the first compiler was backdoored to detect when it is compiling other versions of itself and then inserting the same backdoor in the assembly of the target then how can you trust anything compiled by it?

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

#93

Post by ip26 »

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

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

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

#94

Post by thereddaikon »

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…

I think its even simpler than that. They don't want to reveal any of their secret sauce through available source be it tipping off competitors to hardware designs or just revealing compiler optimizations they believe are valuable enough to keep as trade secrets. Why would they make AMD's job easier?

Intel's C compiler has always played games with non-intel x86 architectures compared to their own.

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

#95

Post by bocklund »

unionpivo wrote: post #33
jraph wrote: post #7

Earlier quoted context omitted.

They are used in High Performance Computing as far as I know. Not systematically though.

I am sure that plenty of existing HPC cluster will remain intel, the interesting question is how much of the new HPC computers will be AMD. or is there any HPC specific reason why Intel would still be preferred?

Several new HPCs are already using AMD [1] and that trend will probably continue if AMD continues to put out competitive products.

[1] See the Top 500 list that, by my count, has 26 of the top 100 HPC systems using AMD EPYC CPUs as of their June 2021 listing https://www.top500.org/lists/top500/list/2021/06/

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

#96

Post by justicezyx »

xamolxix wrote: post #8
xvilka wrote: post #5

Absolutely sensible move. Time for Microsoft to do the same with MSVC.

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.

Well competition is good for consumers but is not for the actual market players. And what's the point of competing in the compiler space?

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

#97

Post by justicezyx »

yakubin wrote: post #48
danuker wrote: post #28

Earlier quoted context omitted.

> Competition is good. On the other hand, collaboration is also good. Why waste time reinventing the wheel?

Because reinventing the wheel is how progress is made. You car isn't made with wheels from 17th century.

Who told you reinventing wheel is how progress made?

Can we be precise here? I never had a memory about a major technical progress being reinventing the wheel.

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

#98

Post by pjmlp »

account42 wrote: post #57
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.

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.

Android Linux fork compiles with clang for ages now. Upstream doesn't want them.

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

#99

Post by lhorie »

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…

Is gcc really starting to fade away? Wasn't Rust working on some backend interop with it? That shiny cool Cosmopolitan thingie was also built on top of it IIRC.

I was also under the impression GCC still outputs better asm than LLVM overall.

Conversely, I recall reading the zig team ran into some woes with the latest LLVM release, and that there's a lot of churn in LLVM APIs from version to version.

(I'm legitimately curious)

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

#100

Post by fay59 »

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 can’t fill all the niches. I don’t think that we’re at a point where research is stifled.

Post reply on HN