6 ms·

> 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 opt

> 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 reason in this marketing language though, tbh: - "Our optimizations are too new" -> So put them behind a feature flag when upstreaming? And why inflict them on icx customers if they are "too new"? What does that even mean? - "Our optimizations are architecture specific" -> ...yes? Emitting good architecture-specific code is the whole point of an optimizing compiler? How is that an argument against upstreaming? - "Other compilers also don't upstream everything" -> That's a non-argument. I get it, there's no money to be made in just implementing all your optimizations in clang directly. But these reasons (together with the repeated emphasis of how they do contribute to LLVM) seem silly. To be clear, I'm all for Intel helping improve LLVM, but the technical arguments for maintaining a separate commercial version don't convince me at all.

formerly_proven 5y ago
> I get it, there's no money to be made in just implementing all your optimizations in clang directly. ICC Classic is legacy/dead and also free now. The LLVM-based DPC++ compilers are free as well. These are only making money indirectly and through support contracts.
- pjmlp 5y ago
  Yeah, but if you give all the golden eggs away, others can offer support contracts as well.
  - bluGill 5y ago
    They can, but who knows more about the issue in question, Intel who designed it, or a third party? This is also a curse to Intel though: they need to ensure their people actually know something, level one support with a bad script and no access to anyone with more ability will get caught quickly when the third party offers better support and generally can figure things out. There are pros and cons for sure. I'm not sure what it best.
CJefferson 5y ago
You over-estimate how much LLVM might want Intel's code dumps. Based on (minor) personal experience of gcc forks, it's not unusual to make some fairly significant change to some major data structure to make your CPU work better, but which would break several other backends. There may not be any nice way of integrating these changes in a way which would make the acceptable upstream, without multi-months of work refactoring huge chunks of the compiler (which would still also need lots of work on all those other architectures, to make them compatible with your changes).
volta83 5y ago
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 optimizations, etc. When you build a tool on top of LLVM, you are buying into this rapidly changing platform. The only proven way of using the LLVM platform competitively is to be part of its future: follow upstream closely, upstream most of your code, and actively participate in the platform evolution so that your competitors can't turn it against you. If you keep most of your code private, following upstream gets very hard. You skip one release, and then its 10x harder, so you skip another release and stop participating in LLVM's evolution cause you'll have to wait years for changes to upstream to land on your compiler. Your competitors do what's best for them, and those can be things that are bad for you, and then you are proper screwed, cause you can't migrate away from LLVM either. Companies like Intel and NVIDIA do this, e.g., nvcc and ISPC are stuck on LLVM 7 (~4 years old), but these companies have built huge technology stacks like CUDA or DPC++ on top of it! Intel and NVIDIA might have enough manpower to maintain their own outdated fork of LLVM forever, but at some point it just stops being LLVM, and these companies are not really much better off than where they started. IMO, building all your technology on top of a platform that either is or can be under your competitors control is just a really bad idea. One would hope that these companies would realize this and contribute back and help the community as much as possible, but in practice they just don't. By the time they realize it, it's already too late.
- varajelle 5y ago
  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!
  - floatboth 5y ago
    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.
fsloth 5y ago
"I get it, there's no money to be made in just implementing all your optimizations in clang directly." Sounds really shortsighted. I would imagine revenue from Intel dev tools is a rounding error in Intel's complete revenue stream?
- kevin_thibedeau 5y ago
  It's a marketing tool to make their competitors look bad. That it is sometimes useful is a secondary side effect.
account42 5y ago
> sometimes because they are very specific for Intel architecture Like the famous check-for-intel-model-instead-of-feature-flag optimization? [0] [0] https://www.agner.org/optimize/blog/read.php?i=49#49 https://www.agner.org/optimize/blog/read.php?i=49#49
phkahler 5y ago
>> 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 be so good, and we know Intel is happy to build untrustworthy chips.
- DSingularity 5y ago
  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?
  - phkahler 5y ago
    You're right, the "trusting trust" compiler hack is way more complicated.
CalChris 5y ago
The Intel post didn't say "Other compilers also don't upstream everything". So you shouldn't put that in quotes. However, that is an actual argument. This isn't GCC where that would be required. This is LLVM where that is allowed. This is a choice, Intel's choice, because LLVM allows that, and it's probably at the corner case level of an Intel-specific icc-specific feature, as in, not particularly generally useful. There is a benefit of this for normal LLVM development as well. It means that Intel is responsible for maintaining it and normal LLVM developers aren't. If I do something that breaks something in the LLVM AMD GPU backend, that's on me. If I do something that breaks something in Intel's code, that's on them.
UncleOxidant 5y ago
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.
- pengaru 5y ago
  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.

formerly_proven 5y ago

> I get it, there's no money to be made in just implementing all your optimizations in clang directly. ICC Classic is legacy/dead and also free now. The LLVM-based DPC++ compilers are free as well. These are only making money indirectly and through support contracts.

pjmlp 5y ago
Yeah, but if you give all the golden eggs away, others can offer support contracts as well.
- bluGill 5y ago
  They can, but who knows more about the issue in question, Intel who designed it, or a third party? This is also a curse to Intel though: they need to ensure their people actually know something, level one support with a bad script and no access to anyone with more ability will get caught quickly when the third party offers better support and generally can figure things out. There are pros and cons for sure. I'm not sure what it best.

CJefferson 5y ago

You over-estimate how much LLVM might want Intel's code dumps. Based on (minor) personal experience of gcc forks, it's not unusual to make some fairly significant change to some major data structure to make your CPU work better, but which would break several other backends. There may not be any nice way of integrating these changes in a way which would make the acceptable upstream, without multi-months of work refactoring huge chunks of the compiler (which would still also need lots of work on all those other architectures, to make them compatible with your changes).

volta83 5y ago

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 optimizations, etc. When you build a tool on top of LLVM, you are buying into this rapidly changing platform. The only proven way of using the LLVM platform competitively is to be part of its future: follow upstream closely, upstream most of your code, and actively participate in the platform evolution so that your competitors can't turn it against you. If you keep most of your code private, following upstream gets very hard. You skip one release, and then its 10x harder, so you skip another release and stop participating in LLVM's evolution cause you'll have to wait years for changes to upstream to land on your compiler. Your competitors do what's best for them, and those can be things that are bad for you, and then you are proper screwed, cause you can't migrate away from LLVM either. Companies like Intel and NVIDIA do this, e.g., nvcc and ISPC are stuck on LLVM 7 (~4 years old), but these companies have built huge technology stacks like CUDA or DPC++ on top of it! Intel and NVIDIA might have enough manpower to maintain their own outdated fork of LLVM forever, but at some point it just stops being LLVM, and these companies are not really much better off than where they started. IMO, building all your technology on top of a platform that either is or can be under your competitors control is just a really bad idea. One would hope that these companies would realize this and contribute back and help the community as much as possible, but in practice they just don't. By the time they realize it, it's already too late.

varajelle 5y ago
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!
- floatboth 5y ago
  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.

fsloth 5y ago

"I get it, there's no money to be made in just implementing all your optimizations in clang directly." Sounds really shortsighted. I would imagine revenue from Intel dev tools is a rounding error in Intel's complete revenue stream?

kevin_thibedeau 5y ago
It's a marketing tool to make their competitors look bad. That it is sometimes useful is a secondary side effect.

account42 5y ago

> sometimes because they are very specific for Intel architecture Like the famous check-for-intel-model-instead-of-feature-flag optimization? [0] [0] https://www.agner.org/optimize/blog/read.php?i=49#49 https://www.agner.org/optimize/blog/read.php?i=49#49

phkahler 5y ago

>> 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 be so good, and we know Intel is happy to build untrustworthy chips.

DSingularity 5y ago
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?
- phkahler 5y ago
  You're right, the "trusting trust" compiler hack is way more complicated.

CalChris 5y ago

The Intel post didn't say "Other compilers also don't upstream everything". So you shouldn't put that in quotes. However, that is an actual argument. This isn't GCC where that would be required. This is LLVM where that is allowed. This is a choice, Intel's choice, because LLVM allows that, and it's probably at the corner case level of an Intel-specific icc-specific feature, as in, not particularly generally useful. There is a benefit of this for normal LLVM development as well. It means that Intel is responsible for maintaining it and normal LLVM developers aren't. If I do something that breaks something in the LLVM AMD GPU backend, that's on me. If I do something that breaks something in Intel's code, that's on them.

UncleOxidant 5y ago

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.

pengaru 5y ago
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.