[LLVMdev] LLVM and newlib progress

[Pertti Kellomäki]

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 LLVM.
First, I did not find any preprocessor symbols that I could use
to identify that we are compiling to LLVM byte code. If there is
one, I'd be happy to hear it, but if not, then it might be a good
idea to define __LLVM__ or something like that in (by) llvm-gcc.
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 solved both of these  issues by creating a shell script that is
just a fall-through to  llvm-gcc, but passes "-emit-llvm -D__LLVM__"
to it. It might be worthwhile to have a similar thing in the LLVM
distribution, that is, a compiler that would identify the target as
LLVM and produce byte code by default.

There was very little to do in terms of porting. Basically
the only thing I needed to tweak in the source code was to define
floating point endiness, which I randomly picked to be
__IEEE_BIG_ENDIAN. Hopefully someone can confirm or correct my
choice.

The next task is to go for the system calls. As I said earlier,
I plan to use intrinsic functions as place holders. Any opinions
how to name them? 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?
-- 
Pertti