Generic target?

Hello LLVM list,

I'm working on a wrapper for LibC and I think it would work a whole lot better for what I'm trying to do if I wasn't forced to use a specific endianness. I'm trying to make it work in such a way that the compiler can generate code for a generic LLVM target such that the bitcodes won't need to have the alignment information or endianness until the final link stage at install time.

Here's the build process currently:

1. The parser is built using LLVM-PEG parser generator which doesn't specify a target. It exports bitcode successfully.

2. The linker library used by the parser code and the main code completes the compiler bitcode thus creating a nearly complete compiler using LLVM-Link.

3. At install time system specific LibC wrapper written in C and compiled with Clang is linked to the incoming bitcode file with LLVM-Link.

4. Opt is invoked on it for LTO.

5. LLC converts the code to Assembly source.

6. The source is now assembled and linked to the real LibC calls contained in the LibC wrapper and the GLibC++ calls to satisfy the linker library are also linked in.

7. Execution reveals a core-dump due to a file handle being converted to a NULL for some reason.

As for step 7, I'd prefer that execution would reveal a "hello world" output to indicate that our code was working. :slight_smile:

Since the LibC wrapper is such simple code I doubt that it's truly to blame so I'm left at a loss to explain it except that the endianness and aligment characteristics of the linker library written using LLVM-C++ are embedded in the bitcode files too soon to allow generic linking. The goal is to produce an endian-agnostic alignment-neutral bitcode in steps 1 and 2. How far away is this in the LLVM side and what can be done to help with a generic target?

Links:
http://sourceforge.net/projects/llvmpeg/ is the project page for LLVM-PEG. (Code is in SVN repository. Click develop tab to access the SVN
browser.)
http://sourceforge.net/projects/llvmlibc/ is the project page for LLVM-LibC wrapper. (Code is in SVN repository.)

Thanks for your time,

--Sam Crow

Hello LLVM list,

I'm working on a wrapper for LibC and I think it would work a whole lot better for what I'm trying to do if I wasn't forced to use a specific endianness. I'm trying to make it work in such a way that the compiler can generate code for a generic LLVM target such that the bitcodes won't need to have the alignment information or endianness until the final link stage at install time.

Here's the build process currently:

1. The parser is built using LLVM-PEG parser generator which doesn't specify a target. It exports bitcode successfully.

2. The linker library used by the parser code and the main code completes the compiler bitcode thus creating a nearly complete compiler using LLVM-Link.

3. At install time system specific LibC wrapper written in C and compiled with Clang is linked to the incoming bitcode file with LLVM-Link.

4. Opt is invoked on it for LTO.

5. LLC converts the code to Assembly source.

6. The source is now assembled and linked to the real LibC calls contained in the LibC wrapper and the GLibC++ calls to satisfy the linker library are also linked in.

What is GLibC++?

7. Execution reveals a core-dump due to a file handle being converted to a NULL for some reason.

Have you looked at the resulting IR? If it's just libc wrappers and
hello world, it ought to be fairly easy to visually inspect.

As for step 7, I'd prefer that execution would reveal a "hello world" output to indicate that our code was working. :slight_smile:

Since the LibC wrapper is such simple code I doubt that it's truly to blame so I'm left at a loss to explain it except that the endianness and aligment characteristics of the linker library written using LLVM-C++ are embedded in the bitcode files too soon to allow generic linking. The goal is to produce an endian-agnostic alignment-neutral bitcode in steps 1 and 2. How far away is this in the LLVM side and what can be done to help with a generic target?

A fair amount of work was done to support "target-independent" IR
in LLVM 2.7. If you omit TargetData, the optimizer conservatively
avoids making any transformations which make memory layout
assumptions. I don't know how widely used it is, but it works quite
well for the things I've seen it used for.

If you're just now trying hello world, it seems more likely that
there's a problem in the wrappers or the main program than an
optimization making memory layout assumptions.

Dan

Reply inlined.

From: Dan Gohman <gohman@apple.com>
To: Samuel Crow <samuraileumas@yahoo.com>
Cc: LLVM Developers Mailing List <llvmdev@cs.uiuc.edu>
Sent: Mon, May 3, 2010 3:34:55 PM
Subject: Re: [LLVMdev] Generic target?

Hello LLVM
list,

I'm working on a wrapper for LibC and I think it would
work a whole lot better for what I'm trying to do if I wasn't forced to use a
specific endianness. I'm trying to make it work in such a way that the
compiler can generate code for a generic LLVM target such that the bitcodes
won't need to have the alignment information or endianness until the final link
stage at install time.

Here's the build process
currently:

--snip--

6. The source is now assembled and
linked to the real LibC calls contained in the LibC wrapper and the GLibC++
calls to satisfy the linker library are also linked in.

What is

GLibC++?

Sorry, I meant LibStdC++.

7. Execution reveals a core-dump due to a
file handle being converted to a NULL for some reason.

Have you looked at

the resulting IR? If it's just libc wrappers and

hello world, it ought to be

fairly easy to visually inspect.

The problem is that a pointer to a FILE structure is bitcasted to an i8 * and when it is read back it is null for some unkown reason. Then I end up with an exception that's the result of our compiled code.

As for step 7, I'd prefer
that execution would reveal a "hello world" output to indicate that our code was
working. :slight_smile:

Since the LibC wrapper is such simple code I
doubt that it's truly to blame so I'm left at a loss to explain it except that
the endianness and aligment characteristics of the linker library written using
LLVM-C++ are embedded in the bitcode files too soon to allow generic
linking. The goal is to produce an endian-agnostic alignment-neutral
bitcode in steps 1 and 2. How far away is this in the LLVM side and what
can be done to help with a generic target?

A fair amount of work was done

to support "target-independent" IR

in LLVM 2.7. If you omit TargetData, the

optimizer conservatively

avoids making any transformations which make memory

layout

assumptions. I don't know how widely used it is, but it works

quite

well for the things I've seen it used for.

If you're just now

trying hello world, it seems more likely that

there's a problem in the

wrappers or the main program than an

optimization making memory layout

assumptions.

After having written the message you replied to, I figured the problem was probably with the fact that the linker library was written in C++ and compiled with LLVM-G++. Since GCC is known to make optimizations involving inlining and endianness independently of the LLVM optimizer, I think that is the culprit.

Also, we were using LLVM 2.6 so we could avoid chasing our tails around with SVN head being in a semi-tested somewhat stable state only. I'll try updating the code to use 2.7 and see if that helps.

Thanks for your response Dan,

--Sam