[LLVMdev] LLVM and newlib progress

[Reid Spencer]

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
> if there were any major problems.

Very nice.

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

That's a good idea, especially for inline ASM things.

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

Oh? Which ones did it not get propagated to?

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

I would think that it would follow the endianness of the host platform,
but someone else might have a more definitive answer.

> 
> The next task is to go for the system calls. As I said earlier,
> I plan to use intrinsic functions as place holders. 

Why? You should be able to compile any assembly code there using LLVM's
inline assembly feature. It is already good enough for compiling (most
of) Linux's inline assembly.

> Any opinions
> how to name them? 

I don't think it's appropriate to use intrinsics for this.  What is the
reason you think you need intrinsics for the system calls?

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

Yes, it should be completely unnecessary to use intrinsics at all unless
there is a good optimization reason. The intrinsics we have are either
lowered generically (e.g. llvm.bswap becomes a series of shifts) or
lowered by the various targets into appropriate code for that target.
However, there shouldn't be any reason to implement the system calls
this way. Again, what issue are you trying to overcome that you think
intrinsics is the solution?

Reid.