Live data from Hacker News

Intel C/C++ compilers complete adoption of LLVM

software.intel.com

131–140 of 169 posts

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

#131
Apple has been the longtime LLVM stalwart, starting from when they first brought out Chris Lattner from the University of Illinois. There are whole subsystems which they've driven such as GlobalISel. However with the M1, Apple has moved wholesale over to ARMv8. Consequently, their efforts are with the AArch64 backend (which they also wrote) and not with X86.

Yes, this announcement has to do with the Intel toolchain above the IR layer but I think it signals that they'll be contributing more patches to the X86 backend as well.

The X86 backend is upstream, and LLVM owns it. Indeed its named Code Owner works for SiFive. Intel won't be grabbing ownership of it. But I think they'll be contributing more to it. This is a good thing for LLVM.

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

#132
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…

LLVM is a somewhat modular system. If Microsoft decided to build their own MSVC front end and AMD decided to build their own AMD64 back end, and Intel decided to build their own special set of x64 optimisers, is it really a monoculture? That sounds more like the GNU form of real software diversity—where you can make your own perfect tool by assembling it from parts.

> and AMD decided to build their own AMD64 back end

They kind of already did. And it's on LLVM, too.

https://developer.amd.com/amd-aocc/

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

#133
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? 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.

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

#134
post #120

Earlier quoted context omitted.

If modern tires are considered reinventing the wooden wheels, sure, then reinventing wheel is the main form of making progress. But I doubt that's how people thinking about reinventing wheel, when they use that phrase to mock others of wasting energy inventing something that has already a very-well-working alternative.

So you would drive a chariot on the same places as a four wheel traction drive Jeep?

Sorry, I was saying that reinventing wheel does not apply to the invention of modern tires...

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

#135
post #109
post #103

Earlier quoted context omitted.

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.

But they also had active and capable browser engine team, isn't it?

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

#136
post #120

Earlier quoted context omitted.

So you would drive a chariot on the same places as a four wheel traction drive Jeep?

Sorry, I was saying that reinventing wheel does not apply to the invention of modern tires...

So why aren't we all using JOVIAL to develop IoT systems?

Apparently it wasn't required to reinvent any other high level language for embedded systems programming, it was already solved problem in 1960.

Why reinvent the wheel for embedded systems programming?

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

#137
post #136

Earlier quoted context omitted.

Sorry, I was saying that reinventing wheel does not apply to the invention of modern tires...

So why aren't we all using JOVIAL to develop IoT systems? Apparently it wasn't required to reinvent any other high level language for embedded systems programming, it was already solved problem in 1960. Why reinvent the wheel for embedded systems programming?

Idk about JOVIAL, but I certain mind too see some modern Ada out there.

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

#138
post #102

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.

ICC like many commercial compilers used the EDG front-end, not their own.

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

#139
post #48

Earlier quoted context omitted.

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.

To be precise:

1. Just because there is Linux, doesn't mean everyone should jump on the Linux bandwagon and abandon all work on illumos, NT, QNX, Fuchsia etc. Focusing everyone on Linux would kill progress.

2. Just because there is x86 or RISC-V, doesn't mean noone should invent new architectures. Apple went with their own and that's what gives them their edge now.

3. Just because there is already Emacs, doesn't mean that all editors should be Emacs mods.

4. And back to compilers, just because LLVM already has optimizers, doesn't mean that other people shouldn't explore other designs for their backends. Especially that LLVM is really slow, and a major bottleneck for new compilers now (see Rust, Zig and Jai e.g.).

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

#140

Earlier quoted context omitted.

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.

To be precise: 1. Just because there is Linux, doesn't mean everyone should jump on the Linux bandwagon and abandon all work on illumos, NT, QNX, Fuchsia etc. Focusing everyone on Linux would kill progress. 2. Just because there is x86 or RISC-V, doesn't mean noone should invent new architectures. Apple went with their own and that's what gives them their edge now. 3. Just because there is already Emacs, doesn't mean…

> illumos, NT, QNX, Fuchsia

Who told you these are reinventing the wheel of Linux?

AFAIK, NT was a consumer desktop OS turned into server and meant to serve the foundation for both consumer and server OS.

QNX was a auto operating system, for which Linux does not work.

Fuschisa is meant to be a unibersal mobile OS.

These are not the same thing as Linux.

I did not meant to label theses as reinventing wheel. If I left you with such impression that was my fault in communication.

Post reply on HN