This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Optimization Diary


Hi,

On Wed, 7 Jun 2006, Daniel Jacobowitz wrote:

> On Wed, Jun 07, 2006 at 11:29:44AM -0700, Devang Patel wrote:
> > And string does not answer localization issue, however for numbers at least
> > there is one precedent to follow.
> 
> I think this discussion has gotten totally sidetracked.  When I said
> I was in favor of strings, I didn't mean messages that would ever be
> displayed!  It's the difference between DW_TAG_compile_unit and
> "compile-unit".
> 
> It is no more work for the producer or for the consumer, it's clearer,
> and conflicts are much less likely.  The only downside is that it's
> larger.

Depending on how it's implemented (via direct encoding or indirect refs to 
a strings section) it can be much larger.  Strings have their advantages, 
but just using them because of the perceived easyness to extend the 
identifier space ... I'm not sure that's a good idea.  When you have 
several hundred .o files you care about debug info size.  And string 
merging in the linker doesn't come for free either.  It's slow enough 
already to link projects with large debug infos.

In general I don't believe very much in strings used as tags or
identifiers in things for consumption by machines.  At least if the
identifier space is controllable a bit.  You either need string compares
to identify them, or make a pass before hand unifying all strings so that
you can use pointer compares.  All the things which make it ugly and slow 
to have strings for machine consumption.  A file-format with built-in 
slowness and bloat.


Ciao,
Michael.
PS: And yes, I don't like XML :-)
PPS: Yes, that comparison stinks.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]