By the time they realize it, it's already too late. 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.
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. 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. 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.Ĭompanies 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! 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.
#Intel c compiler standard code#
If you keep most of your code private, following upstream gets very hard. 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. When you build a tool on top of LLVM, you are buying into this rapidly changing platform. The API and fundamental part of LLVM is its IR, LLVM-IR, which is where most optimizations happen.įrom 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. 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". 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. But these reasons (together with the repeated emphasis of how they do contribute to LLVM) seem silly. I get it, there's no money to be made in just implementing all your optimizations in clang directly. "Other compilers also don't upstream everything" -> That's a non-argument. yes? Emitting good architecture-specific code is the whole point of an optimizing compiler? How is that an argument against upstreaming? "Our optimizations are architecture specific" ->. "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? I don't see any good technical reason in this marketing language though, tbh: This is to be expected and is consistent with other compilers that have adopted LLVM." " Not all our optimization techniques get upstreamed-sometimes because they are too new, sometimes because they are very specific for Intel architecture. Wa_cq_url: "/content/www/us/en/developer/tools/oneapi/dpc-compiler.> 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? Wa_audience: "emtaudience:business/btssbusinesstechnologysolutionspecialist/developer/softwaredeveloper", Wa_english_title: "Intel® oneAPI DPC++\/C++ Compiler", Wa_subject: "emtsubject:itinformationtechnology/aiartificialintelligence,emtsubject:itinformationtechnology/clientcomputing,emtsubject:itinformationtechnology/cloudcomputing", Wa_emtsubject: "emtsubject:itinformationtechnology/aiartificialintelligence,emtsubject:itinformationtechnology/cloudcomputing,emtsubject:itinformationtechnology/clientcomputing", Wa_emtoperatingsystem: "emtoperatingsystem:linux,emtoperatingsystem:microsoftwindows", Wa_emttechnology: "emttechnology:inteltechnologies/edgesoftwarehuborinteledgesoftwarehub,emttechnology:inteltechnologies/intelnetworkingtechnologies/5gpoweredbyinteltechnology", Wa_rsoftware: "rsoftware:inteloneapitoolkits,rsoftware:componentsproducts/inteloneapidpccompiler,rsoftware:developmenttools,rsoftware:developmenttools/compilers", Wa_emtcontenttype: "emtcontenttype:softwareordriver/softwarerepository/softwareoverviews",
0 kommentar(er)
