Read-only data handling: a proposal
Martin Mares
mj@mj.gts.cz
Sun Sep 14 05:13:00 GMT 1997
Hello,
I've looked at the current handling of read-only data (which now outputs
all rodata as soon as it sees them, so they get output even if referenced only
by code deleted in subsequent passes) and I propose the following solution:
- output_constant_def() should not call output_constant() and leave all data
for later processing instead (now it does only when a `defer' mode is switched
on). We also create a new tree node similar to the IDENTIFIER node and linked
to the identifier hash table, but also holding a pointer to the
constant_descriptor struct.
- When assemble_name() gets called, we check the identifier hash table as
usually, but now we also handle the new constant nodes and if we find a
previously unreferenced constant node, we link its constant_descriptor to
another queue (let's call it ready_constants). This should catch all
references, even those made from other read-only data structures.
- Introduce a new function output_ready_constants() which gets called from
assemble_end_function() and assemble_variable() and uses output_constant() to
output all constants linked in ready_constants.
Remaining questions:
- Do any standards say something about ordering of rodata?
- Does any debugging information depend on their placement?
- Does any architecture reference rodata symbols without calling
assemble_name()?
- Does it make sense to introduce a new compiler options to disable
or enable these optimizations? Or maybe doing them only in
optimizing compilation?
- Should we use a similar strategy for static variables and thus
leaving only those which get used?
- Is there something wrong in my idea?
- Any other comments?
Have a nice fortnight
--
Martin `MJ' Mares <mj@gts.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"This sentence contradicts itself -- no actually it doesn't."
More information about the Gcc
mailing list