The great inapplicable attribute debate

[Frits van Bommel]

Michel Fortin wrote:
> On 2009-04-13 09:43:53 -0400, Frits van Bommel 
> <fvbommel at REMwOVExCAPSs.nl> said:
> 
>> (How does this combine with the "D ABI" anyway? I know binary 
>> compatibility between the different compilers is a bit of a pipe dream 
>> at the moment, but the only way that could work would be to 
>> standardize any and all shuffling of class fields...)
> 
> Interesting observation.
> 
> But you don't necessarily need to standardize the shuffling algorithm. 
> If the offsets for fields in a class could be resolved at link time (the 
> compiler could dump the offsets in the object file), then the linker 
> could arange the final executable for any layout. The same could be done 
> for virtual functions too, giving us a true non-fragile ABI capable of 
> supporting changes in the order of member fields and functions.

Some problems I see with this:
* Good luck implementing that for all of OMF (DMD/win), COFF (GDC/win), 
ELF(anything *nix).
* Same for LLVM bitcode, for LDC and any other future compilers based on LLVM. 
Especially because this is a *typed* IR, and optimizations usually work best if 
you don't work around types with pointer<-->int conversions.
* Implementing this without reducing the quality of generated code; some 
architectures allow better instructions if you know the offset is below a 
certain limit, which must then be known at compile-time (except for something 
like LLVM, where link-time is early enough for this if you're generating IR 
instead of native code at first).
* If you do this, you don't know how big a class body is at compile-time 
(because padding is unknown). So the compiler doesn't know what size to allocate 
in the stack frame for 'scope c = new C;"

So yeah, in theory this might be possible, but I don't know of any object format 
that supports all these without it pessimizing the generated code. I just don't 
think it's worth it at the moment.

Though if you feel like extending LLVM to support this... (it's IR object format 
is probably closest to efficiently supporting something like this due to 
arbitrarily-complex constant expression support in IR and inter-module 
optimizations. You might be able to get it to work, as long as the offsets and 
sizes are known by the time the assembler gets involved)

It would certainly allow support for some other cool stuff, like adding fields 
and (virtual) methods to classes from other object files (aka modules).