similar to: [LLVMdev] LLVM bytecode portability

On Thu, 24 Feb 2005, xavier wrote: > Hi, > > I have some questions about LLVM > > Since it is available in several and different platforms like Intel x86, > PowerPc and Sparc, how do you handle the differences between these > platforms in your bytecode? For example, Can a bytecode generated under > MacOS run in the LLVM version under Linux x86? How do you handle things

Anton Korobeynikov schrieb: > Hello, Philipp. > >> unsigned is 16 bit on my target platform. > Could you please show LLVM bytecode? > I've attached the .bc file and the .c source and output files. I compiled dusing llvm-gcc (not configured as cross-compiler though, so that might be the problem). Nevertheless I don't really see why portable source shouldn't be

On Tue, Nov 21, 2006 at 05:33:32PM +0800, Mohd-Hanafiah Abdullah wrote: > Emil: > > I'm using LLVM 1.9 now. When I tried to do what you did I got the > following though: > > $ llvm-g++ -emit-llvm -c x.cpp > $ llvm-link -o=linked.o x.o std/*.o sup/*.o > WARNING: Linking two modules of different target triples! > WARNING: Linking two modules of different target

Emil: I'm using LLVM 1.9 now. When I tried to do what you did I got the following though: $ llvm-g++ -emit-llvm -c x.cpp $ llvm-link -o=linked.o x.o std/*.o sup/*.o WARNING: Linking two modules of different target triples! WARNING: Linking two modules of different target triples! WARNING: Linking two modules of different target triples! ... $ lli linked.o lli((anonymous

On Tue, 21 Nov 2006, Emil Mikulic wrote: > LLVMers, given the same endianness and pointersize, can one mix and > match LLVM bytecode files produced on different platforms? No, not in general. For example, on the mac, printf it often #defined to printf$ldbl, which doesn't exist on linux. System headers generally foil the ability to move stuff around like that. -Chris --

On Thu, 2004-09-16 at 23:45, Chris Lattner wrote: > On Thu, 16 Sep 2004, Andrew Lenharth wrote: > > So I propose that llvm-gcc not consider itself any type of x86-linux (or > > what ever it platform it was compiled on), but rather create a new > > architecture, say llvm (or perhaps 2, one for each bit and little > > endian). Thuse llvm-gcc -dumpmachine would return

Hi, I have a large-ish application I'm trying to build with LLVM, so I replaced g++ in the Makefiles with llvm-g++. This appears to work fine when I pass -Wl,-native to generate an ELF executable, but I want to control the inlining threshold it uses, so I am now passing -Wl,-disable-inlining and -Wa,-disable-inlining, and having it generate LLVM bytecode, then running opt -inlining to generate

Chris Lattner wrote: > On Tue, 21 Nov 2006, Emil Mikulic wrote: >> LLVMers, given the same endianness and pointersize, can one mix and >> match LLVM bytecode files produced on different platforms? > > No, not in general. For example, on the mac, printf it often #defined to > printf$ldbl, which doesn't exist on linux. System headers generally foil > the ability

On Tue, 2004-11-30 at 08:58, Chris Lattner wrote: > On Tue, 30 Nov 2004, Tanu Sharma wrote: > > > I have trouble using the llvm tools.Some of the errors are : > > > > $ llvm-dis prog.bc > > $ llvm-dis: Invalid Top Level Block Length! Type:1, Size:456 (Vers=0, Pos=12) > > Can you explain how you generated this bytecode file? It looks corrupted > or

The -c option tells llvm-gcc to build a bytecode file without linking in the LLVM runtime library. This is similar to the -c option for regular gcc, which you use to build multiple separate .o files that you're going to link into a single executable. If you want to build from a single source file, it's easiest just to compile without the -c option. If you're building from

Hello, Philipp. > unsigned is 16 bit on my target platform. Could you please show LLVM bytecode? -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

On Fri, 17 Sep 2004, Andrew Lenharth wrote: > > Hrm, I would much rather just have LLVM be a drop in replacement for a C > > compiler. As such, it should expose identical #defines to GCC. > > A drop in replacement for "a C compiler" is rather a different > requirement than a drop in replacement for GCC. If the goal is pure GCC > compatibility then sure,

On Mon, 3 Apr 2006, Michael McCracken wrote: > the bytecode with lli - I get the following error: > > $ lli -load=/home/mmccrack/linux/lib/libTau.sh leo-inline-300-tau.bc > ERROR: Program used external function > '__llvm_cxxeh_allocate_exception' which could not be resolved! This is most likely because you are trying to link with llvmgcc, not with llvm-g++. Make sure that

On Tue, 30 Nov 2004, Tanu Sharma wrote: > I have trouble using the llvm tools.Some of the errors are : > > $ llvm-dis prog.bc > $ llvm-dis: Invalid Top Level Block Length! Type:1, Size:456 (Vers=0, Pos=12) Can you explain how you generated this bytecode file? It looks corrupted or something. Also, can you send the actual bytecode file itself? Thanks! -Chris >

hi, I want to know what is exact meaning in the following code. target endian-- %struct..TorRec-- %struct.TorRec-- implementation-- ;<sbyte>[#uses=1/0]-- how to explain them in details? Does anyone give me a guide? thanks yueqiang -------------------------------------------------------------- target endian = little target pointersize = 32 %struct..TorRec = type { int, void ()* }

Hello, When I compile a "hello.c" program with a printf in "main" and use llvm-gcc with a "-c" option: llvm-gcc -c t1.c -o t1.bc and then try to compile t1.bc to native using llc & gcc I get a call to "__main" which is undefined. If I don't use the "-c" option: llvm-gcc t1.c -o t1 I don't get a reference to

Reid Spencer schrieb: > Note that C and LLVM types are *not* the same things (despite the > similar names). We are in the process of making this abundantly clear. > The LLVM IR will soon use names like i8, i16, i32, and i64 (signless > integer quantities of specific sizes, regardless of platform). I had explicitly specified the size in the input code using a uint32_t type, the

Misha Brukman wrote: > I don't know the current status of the LLVA project, so I will let the > current developers chime in. Please send all LLVM and LLVA questions to > llvmdev at cs.uiuc.edu . My apologies for the late reply. > > ----- Forwarded message from N O S P A M <ti_dak at yahoo.com> ----- > > Date: Tue, 17 Jan 2006 09:47:32 -0800 (PST) > From: N O

Is the source code for llva available esp the linux kernel port. Is there a project page for llva ? Mike On 2/3/06, John Criswell <criswell at cs.uiuc.edu> wrote: > Misha Brukman wrote: > > I don't know the current status of the LLVA project, so I will let the > > current developers chime in. Please send all LLVM and LLVA questions to > > llvmdev at cs.uiuc.edu .

On Wed, Jul 23, 2008 at 4:46 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Jul 23, 2008 at 4:23 PM, Scott Graham <scott.llvm at h4ck3r.net> wrote: >> I'm using the PPC backend's output as the "bytecode" for an interpreter >> that I would like to be able to run on both little- and big-endian >> platforms. The split stw's mean