similar to: [LLVMdev] Using LLVM as a cross compiler without fully retargeting gcc?

On Tue, 10 Apr 2007, [ISO-8859-1] Pertti Kellom�ki wrote: > Is this correct? If so, can I just grab any one of the targets > supported by gcc, and modify the data sizes etc. to my liking? Yep, that should work. If you just use -emit-llvm all the time, you should be able to use any target GCC supports. > Any technical reasons to avoid or prefer any one of the targets? Not that I can

There was some discussion in the summer on the mailing list about atomicity and synchronization primitives for LLVM. Is there any progress being made in that department? -- Pertti

As I have explained in another thread, I am in the process of porting portions of newlib to LLVM. The target system has no operating system and a custom processor which may be changed from compilation to compilation. We intend to use LLVM as the front end and generate target specific code from LLVM byte code. For various reasons (whole program optimization being one of them), it would seem to

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 am pretty excited about the recent activity on dependence analysis. The only remaining problem from our point of view is how to get the alias information to the back end instruction scheduler. If I understand things correctly, the alias information basically gets lost in the process of lowering to target instructions. We are interested in the DSP domain, so we really need to get SIMD style

On Apr 2, 2008, at 1:14 AM, Pertti Kellomäki wrote: > I am pretty excited about the recent activity on dependence > analysis. The only remaining problem from our point of view > is how to get the alias information to the back end instruction > scheduler. If I understand things correctly, the alias information > basically gets lost in the process of lowering to target >

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

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

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

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.

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

Chris Lattner kirjoitti: > Question: does GCC 4.1.2 (if it exists) or GCC mainline fix the > problem? If so, we should document 4.1.1 as being buggy. GCC 4.1.2 does not exist yet, but I grabbed the 4.2-20060906 snapshot of GCC and it compiled LLVM without problems. I verified that the hello world example from Getting Started worked, but did not test beyond that. This is on x86 Gentoo. --

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

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

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

Is there some fundamental reason why instructions have a visitor interface but types do not? Or does the support in fact exist and I am just blind? -- Pertti

I am involved in a project where one of the aims is to study the effects of different parallelization strategies on efficiency, power consumption etc. The idea is to do automated design space exploration by varying some parameters (e.g. number of tasks) and measuring their effect. Since we are already using LLVM for other purposes, we thought about using LLVM for analysis and then OpenMP for

Hi Pertti, The boost Python are not (yet) part of LLVM so I suppose it would make most sense to try to makes fixes/changes so they would work for 1.7 and then try to get them into LLVM CVS. It would be good in such a case to ask the author of the bindings again if he would allow this, because basicaly I think he has to agree to the LLVM lincense. cheers, Eric On Apr 20, 2006, at 5:08

On Fri, 9 Nov 2007, [ISO-8859-1] Pertti Kellom�ki wrote: > There was some discussion in the summer on the mailing list > about atomicity and synchronization primitives for LLVM. Is > there any progress being made in that department? Nope, not that I know of. -Chris -- http://nondot.org/sabre/ http://llvm.org/