"With software like that, Apple could become independent of any particular software architecture.
"
Not with the languages they use :)
Neither C, nor C++, nor swift, can be made portable to new architectures through bitcode.
At least, not without language-level changes to each of them.
For example, for C and C++, sizeof is a constant expression, so you can't easily just do something like "defer evaluation to runtime".
Plus ifdefs, struct layout, etc.
ANDF tried to solve these problems many years back.
It may have even been "mostly possible" with c89. But today's languages, not so much.
(Even things like PNaCL and emscripten and what have you have restrictions on what C++ they allow)
> For example, for C and C++, sizeof is a constant expression, so you can't easily just do something like "defer evaluation to runtime". Plus ifdefs, struct layout, etc.
What prevents things like sizeof(T) or alignof(T) from being representable in the LLVM IR in a form that says, "defer to final translation" (to the target architecture)? Does substitution of platform-dependent types, for example, i64 for size_t on x86_64, happen prior to generating the LLVM IR? It would seem useful for me for LLVM IR to retain some platform-dependent types like size_t or intptr_t (deferring until final translation from bitcode to machine code), but maybe that would inhibit certain optimizations.
The short version is, that just isn't possible. Too many things would be unknown, and it is easy in both C and C++ to, at compile time, check the sizeof(size_t) and perform totally different behaviour depending on the value.
> The short version is, that just isn't possible. Too many things would be unknown, and it is easy in both C and C++ to, at compile time, check the sizeof(size_t) and perform totally different behaviour depending on the value.
I can see an issue with template instantiation in C++: for example, if a template uses SFINAE to specialize a template for types of certain sizes, that needs to be evaluated purely at the C++->LLVM stage of compilation.
What is the compile time part of C do you mean? sizeof(T) is evaluated at compile time of course, but it would still produce pseudocode like:
if (4 < 16) { // sizeof(T) replaced with 4
// do something
} else {
// do something else
}
Of course, an optimizer would likely constant-fold that conditional expression to remove the branch entirely, but
I'm having a difficult time seeing how one could perform different behavior at compile time with sizeof(T) in C.
There are many ways to make it perform different behavior at compile time (though admittedly, most are abuse).
The above should compile error, but if you push sizeof evaluation, will not.
"Does substitution of platform-dependent types, for example, i64 for size_t on x86_64, happen prior to generating the LLVM IR? "
In LLVM world, Clang is performing most of the ABI lowering.
For C and C++, the answer is "yes", and "it must happen this way", because struct layout/etc will depend on it.
Not to mention what you want is at some level, impossible in the LLVM IR. LLVM types are not C/C++ types. This leaves you with no type system capable to do the kind of thing you want to do :)
Not with the languages they use :)
Neither C, nor C++, nor swift, can be made portable to new architectures through bitcode.
At least, not without language-level changes to each of them.
For example, for C and C++, sizeof is a constant expression, so you can't easily just do something like "defer evaluation to runtime". Plus ifdefs, struct layout, etc.
ANDF tried to solve these problems many years back. It may have even been "mostly possible" with c89. But today's languages, not so much.
(Even things like PNaCL and emscripten and what have you have restrictions on what C++ they allow)