On Sat, May 23, 2020 at 11:22 PM Paul Dufresne via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > I sometime ask myself what have happened to the "LLVM dream"? > > The idea of LLVM was not to be *just* an intermediate language for the > compiler. The idea was to push code generation as near as possible of > code execution. Because at execution time, you know what are the > specific features of the CPU, and what is used to most often by the user > of the program. > > But it seems CLANG have become a plain replacement of gcc. Just an > alternative compiler. But as I remember the LLVM whitepaper, the idea > was that LLVM generated code was the way programs would be distributed. > It would be possible to generate the assembler at install time. But I > don't think this is the right time because when you install packages... > you have a lot of work to be done. No I think the best time to generate > assembler code is when the CPUs are idle... as a background service. > Sure, you have to optimize the full program because you don't know yet > what features of the program the user will use the most, but this don't > seems such a big problem... because hey... the CPU would not been doing > much useful things anyway. There is the problem of the user trying to > launch the program just after installation... I think it would be > reasonable to show a "finishing compiler of <Foo> program", generate the > assembler code with low optimization, then launch the generated code. It > will still be time later to do a greater level of optimization. > > Is there some technical problems for not packaging LLVM code rather than > CPU specific code? > It's not *completely* dead. This is, in fact, how macOS and iOS apps are submitted to their respective app stores. The final compilation happens on Apple's servers for all supported architectures. It's completely toast on Linux for the same reason FatELF was: nobody liked it. It doesn't work on Windows because of the instability of the Windows runtime ABI (unless you pin to specific runtime ABI, which can lock you out of APIs and features). -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
