similar to: [LLVMdev] cross llvm

Hi all! Is it possible to use LLVM bitcode format for storing cross-platform plugins (for example, sound synths)? Can newest LLVM understand bitcode from previous versions? Thanks! Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100227/d1bab909/attachment.html>

Hello everybody, I'm currently developing my own small operating system as a hobby project in my free time. Until now, I'm using gcc and the binutils to compile my C++ code. I want to try something new and try to use llvm with clang as a C(++) frontend as a compiler. Unfortunately I couldn't find any information about how I can use clang and llvm in a freestanding environment without

On Apr 7, 2010, at 5:07 PM, Andreas Galauner wrote: > > shouldn't be necessary with llvm since I can just translate the bitcode > to any native architecture http://llvm.org/docs/FAQ.html#platformindependent Dan

I am running into some problems when trying to use llvm-ld to link object files, created by llvm-gcc-4.2 at -O4, with the stock libraries available on powerpc-apple-darwin9. In particular, I am finding that the link command... llvm-ld -O4 -native -o molscript molscript.tab.o global.o lex.o col.o select.o state.o graphics.o segment.o coord.o xform.o postscript.o raster3d.o vrml.o regex.o opengl.o

On Jan 29, 2010, at 12: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

Stripf, Timo wrote: > I thought the LLVM IR is target independent and that "llvm-gcc -c -emit-llvm -O2" produces target independent code. > > I'm working on a back-end and use llvm-gcc to first generate the bc file. Afterwards I use llc including the new back-end to produce the assembler file. > > -Timo LLVM IR is very target dependent. The IR knows about things

My two-address target machine has sign-extension instructions to extend i8->i32 and i16->i32. When I compile this simple program: int sext (unsigned a, unsigned b, int c) { return (signed char) a + (signed short) b + c; } I get this IR: define i32 @sext(i32 %a, i32 %b, i32 %c) nounwind readnone { entry: %conv = trunc i32 %a to i8 ; <i8>

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

> > I for one would really like to see object generation become a fully > working feature of the llvm toolchain. Actually, a related thing I've been curious about is the difference between the output of the llvm-gcc-4.2 front end on the Mac and a regular plain vanilla bit code file. The former file can be named a .o and the platform linker now knows how to do LTO while linking

Dan Gohman wrote: > On Apr 19, 2009, at 6:15 PM, Greg McGary wrote: > >> Because sextb_r and sextw_r have destination tied to source operands, >> TwoAddressInstructionPass thinks it needs a copy. However, since the >> sext kills its source, the copy is unnecessary. Why does this happen? >> Is TwoAddressInstructionPass relying on a later pass to notice this

I thought the LLVM IR is target independent and that "llvm-gcc -c -emit-llvm -O2" produces target independent code. I'm working on a back-end and use llvm-gcc to first generate the bc file. Afterwards I use llc including the new back-end to produce the assembler file. -Timo -----Ursprüngliche Nachricht----- Von: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at

Dear all, I cannot find the answer of this question. We all know LLVM IR is portable, but it uses ILP32 and record the target layout within the IR. target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64 :64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" target triple = "x86_64-linux-gnu" It seems it already assigned

On Feb 23, 2011, at 2:47 AM, David Given wrote: > On 02/23/11 02:46, Chris Lattner wrote: > [...] >> Remember that this isn't intended to be something users deal with, it's just an internal implementation detail of the compiler, debugger, nm implementation, etc. > > Can I put in a plea to have as much of LLVM as possible *not* require > knowledge of a single,

On Dec 16, 2008, at 10:34 AM, Jeffrey Yasskin wrote: > I'm on OSX 10.5, trying to build a svn checkout of llvm-gcc. I've also > checked out llvm. Both are synced to r61075. hi Jeffrey, This patch should have fixed the problem: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081215/071210.html Please update and try again, sorry for the breakage! -Chris

I'm on OSX 10.5, trying to build a svn checkout of llvm-gcc. I've also checked out llvm. Both are synced to r61075. I'm using Apple's gcc 4.0.1: $ gcc -v Using built-in specs. Target: i686-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5488~2/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++

Evan Cheng wrote: > On Apr 16, 2009, at 3:17 PM, Greg McGary wrote: > >> Is there some optimizer knob I'm not turning properly? In more complex >> cases, GCC does poorly with two-address operand choices and so bloats >> the code with unnecessary register moves. I have high hopes LLVM >> can do better, so this result for a simple case is bothersome. >>

I guess I should add this to the long list of things Apple has broken that used to work well on NEXTSTEP (the operating system that has been turned into OS X). Now that you mention it, I remember having a problem getting flac to cross-compile in one build step, so I just did the manual lipo glue that you talked about. I assumed it was only because I was too lazy to figure out how to

> > Using built-in specs. > Target: i686-apple-darwin9 > Configured with: /tmp/llvmgcc42.r46865.roots/llvmgcc42.r46865~obj/ > src/configure --disable-checking --enable-werror --prefix=/Developer/ > usr/llvm-gcc-4.2 --mandir=/Developer/usr/llvm-gcc-4.2/share/man -- > enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program- >

Thanks very much for all of your answer. I was confused by definition of 'portable' by my own thinking. Now I Correct that. (ILP32 is in another project, It's my typo. Thanks) So let me make a conclusion about this. LLVM IR can be a portable language, just depending on our front-end configuration or origin language limits. Did I mistake that? Thank a lot all of you. 2010/12/22

On Feb 16, 2008, at 11:32 AM, Evan Cheng wrote: > But I am using llvm-gcc-4.2. Any idea why it's failing? > > Evan All the failing testers are using gcc-4.0 according to the web pages they point at. > On Feb 16, 2008, at 11:24 AM, Dale Johannesen wrote: > >> On Feb 16, 2008, at 7:06 AM, Apache wrote: >>> New Test Failures: >>>