[LLVMdev] Distribution in assembler format
Russell Wallace
russell.wallace at gmail.com
Fri Jan 29 12:45:31 PST 2010
Ah! Yes indeed that is true, and as Dan points out, the issues
described in the FAQ also apply when you're using Clang. Indeed as far
as I can see at least some such issues necessarily arise with any
toolchain that lets you write the sort of low-level/machine dependent
code you at least sometimes want for systems/embedded programming; I
don't think it's really a deficiency of LLVM.
On Fri, Jan 29, 2010 at 8:40 PM, Samuel Crow <samuraileumas at yahoo.com> wrote:
> Hi again,
>
> My point is that your code could not be written in C++ at this time because the only complete compiler for C++ is LLVM-GCC. It will do little endian optimizations on your x86 box and make the resultant bitcode file not work on the ARM processor. It is possible to write an endian-agnostic bitcode file but I don't think all modern LLVM compilers support it. Also the FAQ also indicates other problems with preprocessor macros and
> other evil things that make C inherently not suitable for exporting to
> platform-independent bitcode.
>
> I'm in the process of trying to make a compiler that generates architecture independent bitcode but C and C++ don't have that functionality and cannot be made cross-architecture compliant. At the moment my partner is writing a customized parser generator for LLVM. Since the bitcode it generates was originally written using LLVM-GCC we'll have to audit the LLVM Assembly code for endian discrepancies by hand before we release the full version 1.0 of LLVM-PEG.
>
> The endian problem is not with LLVM's optimizer, the problem is with the LLVM-GCC toolchain and certain aspects of the C programming language itself.
>
> --Sam
>
>
>
> ----- Original Message ----
>> From: Russell Wallace <russell.wallace at gmail.com>
>> To: Samuel Crow <samuraileumas at yahoo.com>
>> Cc: llvmdev at cs.uiuc.edu
>> Sent: Fri, January 29, 2010 2:22:31 PM
>> Subject: Re: [LLVMdev] Distribution in assembler format
>>
>> I don't think I quite understand this... suppose for example you're
>> trying to use an LLVM-based toolchain running on an x86 PC to write
>> code for a device that uses an ARM processor in big endian mode, so
>> you tell the LLVM code generator "generate code for ARM, big
>> endian"... are you saying the optimizer will actually assume the
>> target device is little endian because the development system is
>> little endian (which would of course break things)?
>>
>> On Fri, Jan 29, 2010 at 8:09 PM, Samuel Crow wrote:
>> > Hello Russell,
>> >
>> > Major pitfall #1:
>> > LLVM-GCC does certain optimizations even if all of the optimizations are
>> turned off. These include endian-specific optimizations so to use LLVM as a
>> cross-architecture bitcode, you'll need to wait until Clang supports C++ fully
>> or just stick to C programs for now.
>> >
>> > I've been looking forward to the day that LLVM can be used for
>> cross-architecture development, myself.
>> >
>> > Thanks for asking,
>> >
>> > --Sam
>> >
>> >
>> >
>> > ----- Original Message ----
>> >> From: Russell Wallace
>> >> To: llvmdev at cs.uiuc.edu
>> >> Sent: Fri, January 29, 2010 1:17:12 PM
>> >> Subject: [LLVMdev] Distribution in assembler format
>> >>
>> >> One issue I've been looking at with regard to using LLVM as a compiler
>> >> backend is distribution of programs, particularly on Linux where
>> >> different distributions have different binary package formats and it
>> >> is usual to ship programs as source rather than binary; specifically,
>> >> I'm looking at the general case where the end user may not have (the
>> >> correct version of) LLVM installed, so the compiler can't simply be
>> >> run on the end user's machine.
>> >>
>> >> A solution that occurs to me is to compile as far as assembler on the
>> >> programmer's machine, then ship the .s file (or a small number
>> >> thereof, one per CPU architecture) and assemble it on the user's
>> >> machine (which in most cases will have the GNU assembler installed).
>> >> It seems to me that this ought to work; are there any pitfalls I
>> >> should be aware of?
>> >> _______________________________________________
>> >> LLVM Developers mailing list
>> >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> >
>> >
>> >
>> >
>> >
>
>
>
>
>
More information about the llvm-dev
mailing list