Thinking about "whacky" backends

That said, it seems like it ought to be possible to do the same thing
by emitting bitcode for all supported platform/arch combinations

Wait... is bitcode not platform-agnostic?
I thought it is.

bitcode is, indeed, platform-agnostic.
However, with any language using a preprocessor (IE, C and C++) or a
similar mechanism of determining the underlying OS and architecture, and
in the case of code using it for such a purpose, LLVM would output
different bitcode. As I said in a previous message, replacing
preprocessor conditionals with runtime ones does not seem like a good
option to me. So this would be the simplest alternative I could think
of. Another option would be meta-data, as I suggested previously as well.

compressing them in an archive, then decompressing and either
interpreting or JIT-compiling the appropriate bitcode for the
platform. This would just be a more flexible means to that same end.

Not sure how that is more flexible - care to elaborate?

More flexible to the programmer, not to the system. There are many
pieces of code where, to port between Windows, OS X, iOS, Android, and
PC Linux/*BSD/etc would require a ton of preprocessor work.

I'm also considering that perhaps the real best option here would be to
add a new language feature to C++ (ie, invent a new language that is a
strict superset of C++) for a simplistic control flow construct that
only executes code on the specified system and architecture.
__os(WinXP | WinVista | Win7, IA32) { [... 32-bit Windows code here ...] },
__os(WinXP | WinVista | Win7, AMD64) { [... 64-bit Windows code here ...] },
__os(Linux24 | Linux26, IA32) { [...32-bit Linux code here...] },
__os(Linux24 | Linux26, AMD64) { [... 64-bit Linux code here ...] },
__os( , ) { throw new not_supported_exception(); };
Of course that's only a rough idea and will need a ton of refining, but
it should make my point fairly clear.

I keep forgetting to CC the list. Grrr.

Why not runtime checks? The constant folding and dead-code elimination passes would get rid of any redundant code in a later stage of compilation anyway. The important part, as I see it, is that LLVM already does constant folding and dead-code elimination. Meta-data might require more effort in the long run.

--snip--

Less flexible for the programmer and it differs from normal accepted practice, which is almost always a terrible thing.

There are already many MANY wrappers for OS functionality out there. SImply choosing some of the more popular ones like wxWidgets, OpenAL Soft and Irrlicht should make the job easier. The hardest parts would be converting all of the preprocessor macros into the new function one way or the other, whether it be metadata or runtime checks to constant booleans, and converting the runtimes and build environments to use the new wrapper.

None of these are all-encompassing and it is not practical to make them such. Sometimes the differences are just too large.
What you are suggesting is no different from your original suggestion, besides that you're stripping even more control from the programmer by forcing the use of things like Irrlicht and OpenAL.

If we're going to make a superset of C++, why not ditch C++ outright and just write a code converter to a friendlier high-level language. Sorry if I'm not making much headway with you right now but I'm just trying to save work by using existing code wherever possible to save work.

Most JVMs perform terribly. Even Sun's has had notable performance issues in my experience.
.NET is an excellent case, but then that's only available on Microsoft systems and from numerous benchmarks I've found, Mono is a weak substitute. If you're suggesting that we go the other way around (build native code from a high-level language, as opposed to using native code initially) then that's a terrible idea for myself personally. I lack familiarity with CLR-based languages and absolutely detest some things about Java; I would rather stick with good ol' C++. I prefer strongly-typed languages, so ECMAScript and most other standardized high-level languages are less than desirable for me.

I would much prefer my original suggestion, which is very simple as well and would require even less code than the conversions you're suggesting (and the only additional dependency being an archiving library).

I'm not terribly fond of .NET or Java either. When I was thinking of a friendlier language, I was thinking more along the lines of http://code.google.com/p/tart/ which is already an LLVM language and designed to take advantage of all of LLVM's features internally, such as using opaque types to implement templates and eliminating the preprocessor altogether.

I read the "taste of tart" part of the wiki and didn't care for it, personally.