Multi-architecture binaries

[Jascha Wetzel]

Lutger wrote:
> I've seen some games with multiple executables compiled for different
> architectures. Since the executable size is dwarfed by resources, this
> is no problem for these kind of applications.

yeah, the size issue isn't that important. it's actually more about not
doing anything but adding a compiler switch to get multiple versions.

> How much of a negative impact would your suggested approach have on
> compiler optimizations? (inlining and that sort of thing)

the smallest unit for this approach would be a non-inlined function. any
function that gets inlined within the multi-arch function would be
compiled with the appropriate target as well.
all intraprocedural optimizations work as usual. only optimizations that
change the calling convention are affected. those have to be equal for
all versions of the function because the caller never knows which
version it calls.
in the example where only virtual functions are supported this is not an
issue, since virtual functions have that requirement anyway. for static
functions this has to be ensured explicitly.

> Another thing, what are the benefits of the compiler doing this over
> libraries?

using libraries means that you have to at least compile multiple
versions of each library and have code that loads the appropriate version.
with compiler support it's a lot more convenient and less error prone,
since you do not have to write any additional code or have more complex
build scripts.

> On a related note it may be worth mentioning liboil which implements
> exactly this in a library: http://liboil.freedesktop.org/wiki/

yep, it has the same goal and looking at the source shows how much work
it is. of course that's also because everything is manually optimized.