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