similar to: [LLVMdev] LLVM and libc

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

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

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

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.

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 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 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? >

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

On Fri, 7 Sep 2018 at 17:48, Tim Northover <t.p.northover at gmail.com> wrote: > I looked at your diffs and you've only changed one of the functions to > return SDValue(), you need to change lowerFP_TO_SINT itself too. The > one with the store is just there as an optimization; if it doesn't > trigger (because of your diff) then lowerFP_TO_SINT will still create > a

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

We are using LLVM to target a customizable processor architecture. One of the activities to be supported is architecture exploration, where one explores the processor design space (e.g. connectivity, number of FUs) and tries to find a good match for the application at hand. The exploration needs to be relatively rapid, so targeting and compiling gcc for each of the processor variants is not

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

# HG changeset patch # User Olaf Hering <olaf@aepfle.de> # Date 1341839122 -7200 # Node ID 2dd50c201ca0d3542f3589942ae9e51d33ec7509 # Parent 42f76d536b116d2ebad1b6705ae51ecd171d2581 stubdom: fix errors in newlib rpmlint found a few code bugs in newlib, and marks them as errors after rpm build. Add another newlib patch and apply it during stubdom build. I: A function uses a

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 --

Hi, We have been working on porting llvm-gcc crosscompiler (basically I had to create new dummy target configuration with some minimal information about the our processor, endianess, type sizes, etc.) which compiles llvm bytecode (doesn't compile native binaries nor assembler) for our processor architecture and new llvm target for our custom processor. We already managed to compile also

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. --

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