[LLVMdev] Thinking about "whacky" backends

[Nate Fries]

On 6/2/2011 10:13 AM, Samuel Crow wrote:
> Hi Nate,
>
> I've successfully ported one bitcode from Linux to Mac to Windows.  All were x86 and the program was text-based, but I'd say my LLVM Wrapper would be worth some effort in the future if I could just get some help.  Currently it just wraps StdIO.h with its own functions
Naturally that would work perfectly fine on a similar architecture and 
common dependencies.
I'm a hobbyist game developer, so that is my primary concern. Even using 
a cross-platform game library like Irrlicht or Ogre, there can be 
problems with using the same bitcode for each platform. Especially in 
cases where you may have to implement system-specific code to cover 
cases not provided for by such libraries (wrappers for 
MessageBox/NSRunAlertPanel, Clipboard/Pasteboard, etc)
> * Convert all preprocessor conditionals to regular conditionals so that both the #ifdef parts and the #else parts make it into the bitcode.  Don't worry about bloat since the installer will be able to run constant folding and dead-code elimination to get rid of the unused parts.  The constants will be supplied by the installer in the form of an external bitcode for linkage.  The only exception to this rule would be the guard-defines in .h files.
I'm a huge fan of the C preprocessor, and this just seems like a 
terrible idea.
Better idea would be to generate some sort of metadata from these 
#ifdef's instead.
> * Make sure that the code in the distribution bitcode is endian-agnostic 32-bit code.  A sandbox will be needed on 64-bit systems or else a separate 64-bit bitcode package will still be required.
>
Endian agnosticism without using the preprocessor just seems... burdensome.
However, if I'm grabbing the correct information here, you're saying 
that bitcode for x86 Linux would function on 32-bit ARM, PPC, and SPARC 
Linux (if endian-agnostic)?
> * Make sure all external dependencies including LibC runtimes are accessed from the wrapper rather than the native code from the bitcode.  All external libraries are system-specific.
The meaning here being that I need all dependencies to be part of the 
bitcode, as opposed to being natively linked later? This simply isn't 
practical for games.