llvm dev - Sep 2008 - [LLVMdev] Architecture Dependency of LLVM bitcode (was Re: compile linux kernel)

And the code of the Linux kernel compiled by LLVM is also very arch 
depended,
despite any loader and hw access will not work inside the standard LLVM JIT,
all the MMU and low-level access stuff will make no sense on a machine other
than what was enabled while compiling the kernel. E.g. you would need a 
whole
virtualized HW architecture ala Qemu (et al.) along the JIT.

Of course in theory one could setup such an infrastructure to JIT low level,
kernel and driver code, just throwing the i386 linux kernel source on LLVM
will not bring you there.

Yours,

Daniel Berlin wrote:
> No, this is not the case.
>
> Just because you compile something to LLVM IR does not make the thing
> you compiled work on every architecture.
> You may even be able to retarget it to any architecture (it depends),
> but this in no way means the result will *actually work*.
> The LLVM IR generated by llvm-gcc is very architecture dependent.
> Theoretically you could make a C compiler that was mostly C compliant
> and produced architecture independent LLVM IR.
> llvm-gcc is not this compiler, however.
>
> On Sun, Sep 28, 2008 at 1:07 AM, Ashish Bijlani
> <ashish.bijlani at gmail.com> wrote:
>   
>> does that mean .o generated with  gcc (.c -> .s and .s -> .o)
will not
>> contain llvm ir?
>>
>> i meant, final kernel bitcode ir arch independent and can be JIT with
>> any arch-specific backend. Is it not the case?
>>
>> thanks,
>> ashish
>>
>> On Sat, Sep 27, 2008 at 10:43 PM, Andrew Lenharth <andrewl at
lenharth.org> wrote:
>>     
>>> On Sat, Sep 27, 2008 at 8:08 PM, Ashish Bijlani
>>> <ashish.bijlani at gmail.com> wrote:
>>>       
>>>> If I use GCC to generate asm-offsets.s file, then the build
system go
>>>> ahead but fails when it generates .so files as Andrew pointed
out.
>>>>         
>>> You have to generate this with gcc.  .c -> .s and .s -> .o
need gcc,
>>> .c -> .o can use llvm-gcc.  The combination has to be fixed up
in
>>> final linking.
>>>
>>>       
>>>> Now, If the build systems generates .so files, then it will be
>>>> difficult o actually generate fully arch-independent kernel
code,
>>>> isn't it?
>>>>         
>>> A llvm compiled kernel is in no way arch-independent.  It is very
very
>>> arch dependent.
>>>
>>> Andrew
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>       
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>     
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   

-- 
  René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
  http://exactcode.de | http://t2-project.org | http://rene.rebe.name

Watching this thread, it occurs to me that the "V" in "LLVM"
is creating
confusion. So far as I know, LLVM is the first project to use
"virtual"
to refer to the instruction set of the intermediate form. I understand
why this labeling made sense (sort of), but it was unfortunate. The
machine is abstract, not virtual, and the use of "virtual" here is so
out of keeping with any other use of the term that it really does
generate confusion.

Is this worth a FAQ entry?

On 29.09.2008, at 11:53, Jonathan S. Shapiro wrote:
> Watching this thread, it occurs to me that the "V" in
"LLVM" is
> creating
> confusion. So far as I know, LLVM is the first project to use  
> "virtual"
> to refer to the instruction set of the intermediate form. I understand
> why this labeling made sense (sort of), but it was unfortunate. The
> machine is abstract, not virtual, and the use of "virtual" here
is so
> out of keeping with any other use of the term that it really does
> generate confusion.
The topic whether LLVM bitcode is independent of the target platform  
was raised several times on the mailing list, but it was never  
discussed in detail. I would appreciate learning more about the  
following questions:

-  Is the architecture dependence of LLVM IR only an artifact of llvm- 
gcc producing architecture dependent results?
- What architecture-specific features are present in the IR that  
prevent running the same LLVM bitcode on different architectures?
> Is this worth a FAQ entry?

I would definitely appreciate such a FAQ entry.

Best regards,
  Christian

Hello Jonathan,

Actually it is the second project that I know of that used the term Virtual to
describe the intermediate instruction set.  Virtual Processor was part of a
failed attempt by the Tao Group and Amiga Inc. to bring a common set of runtimes
and instruction sets to handheld devices (called AmigaDE).  Later, certain
optimizations appeared in Java allowing it to catch on instead.  In an effort to
minimize their losses, Amiga released a subset of it with a hosted operating
system called AmigaAnywhere and a few titles were released on it.

To make a long story short, VP Assembler was replaced by some GCC
cross-compilers and renamed AmigaAnywhere 2.0 .  For more information about
this, refer to http://amiga.com/developers/ .

This is trivia however as there isn't even a Wikipedia article about VP
Assembler now.

--Sam

--- On Mon, 9/29/08, Jonathan S. Shapiro <shap at eros-os.com> wrote:
> From: Jonathan S. Shapiro <shap at eros-os.com>
> Subject: Re: [LLVMdev] compile linux kernel
> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Date: Monday, September 29, 2008, 4:53 AM
> Watching this thread, it occurs to me that the "V"
> in "LLVM" is creating
> confusion. So far as I know, LLVM is the first project to
> use "virtual"
> to refer to the instruction set of the intermediate form. I
> understand
> why this labeling made sense (sort of), but it was
> unfortunate. The
> machine is abstract, not virtual, and the use of
> "virtual" here is so
> out of keeping with any other use of the term that it
> really does
> generate confusion.
> 
> Is this worth a FAQ entry?
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev