On Thursday, May 28, 2020 9:41:54 PM MST Paul Dufresne via devel wrote:
On 2020-05-28 7:36 a.m., Dridi Boukelmoune wrote:
> On Tue, May 26, 2020 at 12:07 PM Jan Kratochvil
>
> <jan.kratochvil(a)redhat.com> wrote:
>> On Sun, 24 May 2020 05:21:05 +0200, Paul Dufresne via devel wrote:
>>> 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.
>>
>> In Free Software you have that already - it is called the source code.
>> If you want host-specific optimizations use Gentoo Linux.
>
> One could implement a DNF plugin that builds packages locally since we
> have source RPM repositories.
Well... when I said code generation as near as possible of code
execution... I did not want to start compiling from source code, which
take way too long in my opinion. LLVM Intermediate Representation is a
bit like compiled Java, or run-everywhere .NET exe, that are not yet
generated code for a specific CPU. But unlike compiled Java or .Net
intermediary language that are specific to one language or family of
language, LLVM intermediate language is like a RISC assembler with
unlimited registers (as far as I know). Also using some Single Static
Assignment, like used in C compilers to make it easier to do
transformations on the code. LLVM IR can be run with *"lli* directly
executes programs in LLVM bitcode format. It takes a program in LLVM
bitcode format and executes it using a just-in-time compiler or an
interpreter."
But when I proposed that, I was not aware main developer had been hired
by Apple. And like people have replied before, they don't like the Clang
(C, C++ LLVM-based compiler) I guess in good part because of the more
permissive license than GPL it use: Illinois/NCSA license.
Paul,
What benefit do you see in the overhead of LLVM IR, compared to standard
packages?
--
John M. Harris, Jr.
Splentity