[LLVMdev] Distribution in assembler format
russell.wallace at gmail.com
Fri Jan 29 12:22:31 PST 2010
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 <samuraileumas at yahoo.com> 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,
> ----- Original Message ----
>> From: Russell Wallace <russell.wallace at gmail.com>
>> 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
More information about the llvm-dev