[LLVMdev] Generic target?

[Samuel Crow]

Reply inlined.



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

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