digitalmars.D.bugs - Backend OMF structure
- TonyI <foo bar.com> Feb 25 2007
Not really a bug per-se, rather an observation... The compiler seems to be generating LEDATA32, PUBDEF32, and LINNUM32's when the offsets involved would fit just fine in the 16 bit variants of those record types. In the case of the LINNUM32's this results in considerable bloat of the resultant OBJ, the others only waste 2-bytes per. Here's some example output from an OMF optimizer I've been working on. In this case the original OBJ was: 02/25/2007 08:31p 39,282 DUMP.obj After munging it over and optimizing it it shrunk down to : 02/25/2007 08:37p 36,548 DUMP.obj The gains came from: Record morphing 32 bit to 16 bit Do3216Opt() 4 SEGD32->SEGDEF(8 bytes saved) 29 LEDA32->LEDATA(58 bytes saved) 1 LIDA32->LIDATA(2 bytes saved) OptLINN32()  LINN32 records converted to LINNUM records  bytes saved in OBJ size MvLinnToBottom() - 16 LINNUM/32 records moved. LinnSort() - 15 LINNUM/32 record orders shuffled LinnMerge() 15 LINNUM/32 records merged Re-optimizing line numbers after dup purge MvLinnToBottom() - 1 LINNUM/32 records moved. LinnSort() - 0 LINNUM/32 record orders shuffled LinnMerge() 0 LINNUM/32 records merged 2 EXTDEF/LEXTDEF/COMDEF/LCOMDEF/CEXTDEF type records merged 2 PUBD32 record elements merged Adding an optimization to generate threaded fixups further knocked the OBJ down to: 02/25/2007 08:42p 34,366 DUMP.obj Just under 5K off a 39K OBJ is a pretty decent reduction in size...
Feb 25 2007