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, > > --Sam > > > > ----- 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 >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > >
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 > > > > > > > > > >
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 >> > >> > >> > >> > >> > > > > > >