[LLVMdev] Generic target?

Dan Gohman gohman at apple.com
Mon May 3 13:34:55 PDT 2010


On May 2, 2010, at 10:45 AM, Samuel Crow wrote:

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





More information about the llvm-dev mailing list