search for: targetindep

...can use with X-86 version of > llvm-gcc front end to generate .bc file for sparc backend. Suppose > I have the include files. > Sure you can, but the code won't work in general. See the other thread about arch portability and also: http://llvm.org/docs/tutorial/LangImpl8.html#targetindep -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080929/ceefa36a/attachment.html>

...ay, I've got your point. sizeof() constant expression is > calculated > during wrong stage of compilation process. Thanks for pointing it out! Yes, not to mention stuff like: #ifdef __i386__ or: case sizeof(foo): This is addressed here: http://llvm.org/docs/tutorial/LangImpl8.html#targetindep Note that this doesn't affect cross compilation: you just need to configure llvm-gcc as a proper cross compiler. This just means that llvm won't magically make your C code portable for you. Real portable languages don't suffer from these problems. -Chris

Hi. I successfully build llvm backend2.3 for sparc/solaris, but failed to build LLVM front end of Sparc/Solaris. I'm wondering if there is any option I can use with X-86 version of llvm-gcc front end to generate .bc file for sparc backend. Suppose I have the include files. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL:

...; - Is the architecture dependence of LLVM IR only an artifact of llvm- > gcc producing architecture dependent results? No, it inherent to any C compiler. The preprocessor introduces target specific details and things just go downhill from there: http://llvm.org/docs/tutorial/LangImpl8.html#targetindep If you start from a target-independent *language*, you can generate target independent LLVM IR. > - What architecture-specific features are present in the IR that > prevent running the same LLVM bitcode on different architectures? Many things are target independent, but the most signific...

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

On Nov 11, 2008, at 3:51 PM, Peter Shugalev wrote: > Owen Anderson wrote: >> If you configure it as a cross-compiler for 64-bit x86 Linux and >> feed it >> the appropriate header files, it will produce the same output on any >> platform. However, that output will not be executable on most >> platforms, just on 64-bit x86 Linux. The problems go beyond pointer

Owen Anderson wrote: > What about something much simpler: memcpy'ing an array of structs > around. The number of bytes to be memcpy'd is dependent on the padding > of the struct. Anyway, I've got your point. sizeof() constant expression is calculated during wrong stage of compilation process. Thanks for pointing it out! -- Best Regards Peter Shugalev

Hi, Chris Lattner wrote: > Yes, not to mention stuff like: > > #ifdef __i386__ > > or: > case sizeof(foo): > > This is addressed here: > http://llvm.org/docs/tutorial/LangImpl8.html#targetindep > > Note that this doesn't affect cross compilation: you just need to > configure llvm-gcc as a proper cross compiler. This just means that > llvm won't magically make your C code portable for you. Real portable > languages don't suffer from these problems. I...

> If you want to use llvm-gcc as a cross compiler, you must configure it as > a cross compiler, and compile the output with the appropriate cross > toolchain. LLVM does not implicitly make your code portable, see: > http://llvm.org/docs/tutorial/LangImpl8.html#targetindep > > for example. > > -Chris Hm.. so the C backend works differently if I configure LLVM to be a cross compiler? I am using a cross-compile toolchain as a backend (feeding it the "llc -march c" output), so I'm a bit confused. I'm not looking for a target independent IR...

Hi, I'm still working on this problem by first trying code without the Altivec intrinsics. I'm trying to use the cross compiler on the c code outputted by "llc -march c" and have run into this linker problem (spewed by the cross compiler): Command line : error: L0039: reference to undefined symbol .fopen64 in file /tmp/cc4tgLu5.o Command line : error: L0039: reference to