similar to: [LLVMdev] Byte code libraries and linking

To follow up on my own post: > The only concern here is that this brings in all of libc, but I > suppose it should be easy enough to run dead code elimination on > linked.bc to shake out the unused bits? Cursory browsing of LLVM optimization passes did not turn up anything directly applicable, at least "opt -adce" and "opt -globaldce" did not reduce the size of the

On Wed, 15 Nov 2006, [ISO-8859-1] Pertti Kellom�ki wrote: > I succesfully built a byte code version of newlib, so I tried to > use it like this: > > $ llvm-link hello.bc $NEWLIB/libc.a -o linked.bc > > but apparently llvm-link only understands byte code files. Right, llvm-link is the low level bytecode linking interface, not really useful for this sort of use. > Does it

We are going to use LLVM in a compiler project for transport triggered processors. See Wikipedia for more on transport triggering: <http://en.wikipedia.org/wiki/Transport_Triggered_Architectures>. One thing we need is some sort of libc. We are targeting embedded systems, and I have been looking at things like newlib. Are there people out there doing something similar? Or any advice or

I have been browsing through the newlib documentation at <http://sources.redhat.com/newlib/> and pondering about how newlib relates to LLVM. Comments welcome, again. As I see it, there are basically two parts of libc that need to be considered. Much of libc is stuff like atoi(), isalpha(), etc. which are just convenience routines written in ANSI C. For these, it should be sufficient to

I managed to compile newlib with llvm-gcc yesterday. That is, the machine independent part is now basically done, and the syscall part contains no-op stubs provided by libgloss. I haven't tested the port yet, but since newlib has already been ported to many architectures, I would be pretty surprised if there were any major problems. A couple of things I noticed when configuring newlib for

Reid Spencer kirjoitti: > So, now I'm not sure what you're talking about. Is > libgloss part of newlib? If so, please note that it is not llvm-gcc's > job to pass CFLAGS down. That would be a bug in the newlib makefiles. :) Sorry for being obtuse. Yes, if there indeed is a bug, it is in the newlib build system. I was trying to compile newlib with llvm-gcc. The need for

Hi Reid, I'll write a separate post about the intrinsics, but just a quick note about the CFLAGS issue. Reid Spencer kirjoitti: > On Thu, 2006-11-09 at 15:29 +0200, Pertti Kellomäki wrote: >> Another related thing is that even when I defined -emit-llvm in >> what I thought would be a global CFLAGS for all of newlib, it did >> not get propagated to all subdirectories.

Hi Pertti, On Thu, 2006-11-09 at 18:41 +0200, Pertti Kellomäki wrote: > Hi Reid, > > I'll write a separate post about the intrinsics, but just > a quick note about the CFLAGS issue. Okay. > > Reid Spencer kirjoitti: > > On Thu, 2006-11-09 at 15:29 +0200, Pertti Kellomäki wrote: > >> Another related thing is that even when I defined -emit-llvm in >

On 13 Jan 2010, at 20:34, Nick Lewycky wrote: > On 13 January 2010 12:05, Mark Muir <mark.i.r.muir at gmail.com> wrote: > > But... now there's a small problem with library calls. Symbols such as 'memset', 'malloc', etc. are being removed by global dead code elimination. They are implemented in one of the bitcode modules that are linked together (implementations

Hi Pertti, On Thu, 2006-11-09 at 15:29 +0200, Pertti Kellomäki wrote: > I managed to compile newlib with llvm-gcc yesterday. That > is, the machine independent part is now basically done, and > the syscall part contains no-op stubs provided by libgloss. > I haven't tested the port yet, but since newlib has already > been ported to many architectures, I would be pretty surprised

On Thu, 9 Nov 2006, Reid Spencer wrote: >> Currently there are a few intrinsics that have >> to do with libc, like llvm.memcpy and llvm.memmove. However, I >> would personally prefer less pollution in the intrinsic name space, >> so I would propose naming the intrinsics with a llvm.libc prefix, >> e.g. llvm.libc.open and so forth. Any strong opinions on this? >

On 13 Jan 2010, at 16:43, Nick Lewycky wrote: > Mark Muir wrote: >> - Run the existing Clang tool on each source file, using -emit-llvm to generate a .bc file for each module. >> - Run llvm-link to merge them into a single .bc file. >> - Run llc to generate a complete machine assembly. >> >> However, with optimisations enabled, the resulting code is not as

Chris Lattner kirjoitti: > There isn't any really good reason to have an llvm intrinsic for write, > just leave 'write' as an external function. So is the opportunity for inlining the only reason for e.g. the llvm.memcpy intrinsic? -- Pertti

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 13 January 2010 12:05, Mark Muir <mark.i.r.muir at gmail.com> wrote: > On 13 Jan 2010, at 16:43, Nick Lewycky wrote: > > > Mark Muir wrote: > >> - Run the existing Clang tool on each source file, using -emit-llvm to > generate a .bc file for each module. > >> - Run llvm-link to merge them into a single .bc file. > >> - Run llc to generate a

Mark Muir wrote: > > On 13 Jan 2010, at 20:34, Nick Lewycky wrote: > >> On 13 January 2010 12:05, Mark Muir <mark.i.r.muir at gmail.com >> <mailto:mark.i.r.muir at gmail.com>> wrote: >> >> >> But... now there's a small problem with library calls. Symbols >> such as 'memset', 'malloc', etc. are being removed by

On Wed, 22 Nov 2006, [ISO-8859-1] Pertti Kellom�ki wrote: > Aside from stuff that depends on system headers, are there any other > dependencies on the host system? In other words, will llvm-gcc produce > exactly the same byte code for a given set of source files regardless of > where compilation takes place? This has obvious implications on Yes. Many aspects of the target compiler

This is in response to Reid's and John's comments about intrinsics. The setting of the work is a project on reconfigurable processors using the Transport Triggered Architecture (TTA) <http://en.wikipedia.org/wiki/Transport_triggered_architecture>. For the compiler this means that the target architecture is not fixed, but rather an instance of a processor template. Different

Hello all, I am trying to build llvm 1.8a with gcc 4.1.1 and I get the attached error. Are there any easy workarounds or should I just try another version of gcc? -- Pertti -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: build-error URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060901/350fb4a1/attachment.ksh>

I fixed my immediate problem by using a different version of gcc. Chris Lattner kirjoitti: > The offending line of code looks fine on our side, > but there could be something I'm missing. For what it is worth, I've run into problems with boost_concept_check before when using Boost.Python. Some versions of gcc worked fine, while others gave error messages relating to