Read-only data handling: a proposal

[Jeffrey A Law]

  In message < 19970914141243.18489@albireo.mj.gts.cz >you write:
  >    Remaining questions:
  > 
  > 	- Do any standards say something about ordering of rodata?
Usually not.  Especially since newer linkers may reorder items in
various data segments to reduce the number of load address insns
needed to access readonly data (and read/write data too).

  > 	- Does any debugging information depend on their placement?
I wouldn't think so, but sometimes we get suprised.  Order does matter
for commons, but you can't have a common in a readonly data area :-)

  > 	- Does any architecture reference rodata symbols without calling
  > 	  assemble_name()?
No.

  > 	- Does it make sense to introduce a new compiler options to disable
  > 	  or enable these optimizations? Or maybe doing them only in
  > 	  optimizing compilation?
It might make sense to only do them during an optimizing compilation.  It
also brings up the issue that you might want some constants that aren't
explicitly referenced (so that you can use them in the debugger).

  > 	- Should we use a similar strategy for static variables and thus
  > 	  leaving only those which get used?
In theory, yes.  In theory you can also put the statics into a block and
reduce the number of load address insns to reference static data.

  > 	- Is there something wrong in my idea?
Unfortunately, yes.

Well, more correctly, it depends.  Are you suggesting that output of
constants be deferred until the end of a compilation unit, or end of
a function?  If you're deferring to the end of a compilation unit, then
you have to arrange for the tree nodes to be copied onto a permanent
obstack.  This can get quite hairy -- I did it for static variables a
few years back and we dropped the code after a while because it was
unmaintainable.

Jeff