Re: [RFC] Optimization Diary

[Geoffrey Keating]

On 06/06/2006, at 5:11 PM, Daniel Berlin wrote:

Geoffrey Keating wrote:

On 06/06/2006, at 4:58 PM, Daniel Berlin wrote:

Geoffrey Keating wrote:

Daniel Berlin <[EMAIL PROTECTED]> writes:

Tom Tromey wrote:

"Devang" == Devang Patel <[EMAIL PROTECTED]> writes:

Devang> This version removes internal radar numbers and replaces s/

Devang> DW_AT_APPLE.../DW_AT_GNU...


dumb :-).

I do have a few questions and concerns.

I read this. I'm not anywhere near an expert in dwarf or anything related to this proposal, so please bear with me if I say something

In addition to Tom's concerns, it seems to me to be a *really bad
idea*
to try to come up with integer values for every single message,
instead
of just placing a string there.

One issue here is that this interacts poorly with
internationalization.
No matter what you do, you'll need to have a

by not putting it in every object file.

table of possible strings somewhere, so you might as well save space

I believe this is a red herring.

tell it to only deal in one language.

We control the debug output machinery generating this, and can simply

I'm not concerned about what goes into the .o file, but what gets
displayed on the screen.  We cannot tell users to "deal in one
language".

You still need to be able to display the message for each number in all

the languages you want, so it's going to be stored somewhere, you
haven't solved the problem, just moved it completely to the consumer.

Yes.  However, you also get smaller .o files.

Trying to catalogue and assign a permanent place and number to every
single optimization message a compiler can generate is a much much
much
worse idea, IMHO.

Alternatively, we could put *every* supported language into the .o
file.  But that bloats object files even more...

in one language, and having someone who can't read those messages
optimize and profile your application in another language, is a
significant enough use case to be worried about.

I have a very hard time believing that compiling and outputting messages

Right above, you said "We control the debug output machinery generating this, and can simply tell it to only deal in one language." Here, you seem to be implying that the messages should be localised in the language the compiler is going to output messages in. I suppose you could output both, but that still bloats object files more than just using numbers.

smime.p7s
Description: S/MIME cryptographic signature