[RFC] Optimization Diary

[RFC] Optimization Diary

[Devang Patel]

[-- Attachment #1: Optimization Diary 0.12.pdf --]
[-- Type: application/pdf, Size: 89547 bytes --]

[-- Attachment #2: Type: text/plain, Size: 68 bytes --]


I welcome your feedback/questions/suggestions.
Thanks,
-
Devang

Re: [RFC] Optimization Diary

[Devang Patel]

[-- Attachment #1: FSF Optimization Diary 0.12.pdf --]
[-- Type: application/pdf, Size: 88716 bytes --]

[-- Attachment #2: Type: text/plain, Size: 340 bytes --]


This version removes internal radar numbers and replaces s/ 
DW_AT_APPLE.../DW_AT_GNU...

I did not intend to send original one and I had this ready but  
anyway....
-
Devang


On Jun 2, 2006, at 4:01 PM, Devang Patel wrote:

> <Optimization Diary 0.12.pdf>
>
> I welcome your feedback/questions/suggestions.
> Thanks,
> -
> Devang
>
>
>

Re: [RFC] Optimization Diary

[Tom Tromey]

>>>>> "Devang" == Devang Patel <dpatel@apple.com> writes:

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

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
dumb :-).

I do have a few questions and concerns.

* Why put the optimization diary into the object file?
  Why not just have -Wdiary and print it along with all the warnings?
  (I'm sure there's an answer to this, it would just be nice if it
  were in the document...)

* DW_AT_GNU_OD_cmd - it seems strange for this to be defined in terms
  of text highlighting.  Why have a separate code here for "dead
  code" instead of just marking a text region and having a new _msg
  value meaning "dead code"?

* DW_AT_GNU_OD_category

  The last value is 0x0000 0016.  That seems wrong, I think it should
  end in 0010.

  What are "action trails"?

  Why is the action bit needed?  The example in the text seems wrong,
  since there is an explicit _msg value for "function is inlined",
  and multiple values for why a function might not be inlined.

  How would the user find out what parameter is referred to by a
  parameter manipulation hint?  I don't see where this is recorded.

* DW_AT_GNU_OD_msg

  I presume that GCC will somehow maintain the canonical values here.
  It seems important that there be a central process for registering
  these so that weird divergences don't crop up over time.  Also
  perhaps a "vendor extension" range should be specified?  In any
  case, the mechanisms here ought to be documented.

A nit:

* The first example is oddly formatted.  The blue region encompasses
  an entire comment, but the salmon (? nice color choice :) region
  stops before the '*/'.  And... surely the diary won't be marking
  text regions corresponding to comments anyway?  I feel like I'm
  probably misunderstanding the point of this highlighting.

Tom

Re: [RFC] Optimization Diary

[Devang Patel]

Tom Tromey wrote:
>>>>>> "Devang" == Devang Patel <dpatel@apple.com> writes:
>>>>>>             
>
> Devang> This version removes internal radar numbers and replaces s/
> Devang> DW_AT_APPLE.../DW_AT_GNU...
>
> 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
> dumb :-).
> I do have a few questions and concerns.
>
> * Why put the optimization diary into the object file?
>   Why not just have -Wdiary and print it along with all the warnings?
>   (I'm sure there's an answer to this, it would just be nice if it
>   were in the document...)
>   
I'll use separate email to answer this because it needs some
explanation and it may spawn its own little email thread.

> * DW_AT_GNU_OD_cmd - it seems strange for this to be defined in terms
>   of text highlighting.  Why have a separate code here for "dead
>   code" instead of just marking a text region and having a new _msg
>   value meaning "dead code"?
>   
In the case of "dead code" we could use _msg. However, _cmd is available to
trigger some actions in tools that use this information. If we let our
imaginations run wild then for example, lead developer towards
 __restrict  documentation (i.e. launch lang. standard doc in one window
and open particular page).

Usually  tools directly communicate_msg in plain English without performing
any action.
> * DW_AT_GNU_OD_category
>
>   The last value is 0x0000 0016.  That seems wrong, I think it should
>   end in 0010.
>   
Yes.
>   What are "action trails"?
>   
For example, Loop A is unrolled. It is not a parameter manipulation hint,
it is not a limitation and it is not a hint to developers. It is just a 
report
of what optimizer did. This is default category.
>   Why is the action bit needed?  The example in the text seems wrong,
>   since there is an explicit _msg value for "function is inlined",
>   and multiple values for why a function might not be inlined.
>   
It is used to provide distinctive feed back for action performed vs
actions avoided. IDE may use different colors for actions performed vs
actions avoided (blue vs salomn color :)

>  How would the user find out what parameter is referred to by a
>   parameter manipulation hint?  I don't see where this is recorded.
>   
This should be encoded in msg text. It bit is used to distinguish
build setting hint vs code change hint. Increase inline limit vs
use __restrict. Parameter manipulation hints may be handled by
build engineer in a big team, however you need code expert to
justify use of __restrict.
> * DW_AT_GNU_OD_msg
>
>   I presume that GCC will somehow maintain the canonical values here.
>   It seems important that there be a central process for registering
>   these so that weird divergences don't crop up over time.  Also
>   perhaps a "vendor extension" range should be specified?  In any
>   case, the mechanisms here ought to be documented.
>   
Yes. However, honestly, I do not know what is the best way to handle
this. I am open for suggestion and I presume there is a established
way to communicate such values, that are owned by GCC, to other tools.
> A nit:
>
> * The first example is oddly formatted.  The blue region encompasses
>   an entire comment, but the salmon (? nice color choice :) region
>   stops before the '*/'.  And... surely the diary won't be marking
>   text regions corresponding to comments anyway?  I feel like I'm
>   probably misunderstanding the point of this highlighting.
>   
The second example is oddly formatted. Blue and salmon colored
comments are generated by IDE based on diary entries. And IDE selected
color based on action bit.

-
Devang

Re: [RFC] Optimization Diary

[Tom Tromey]

>>>>> "Devang" == Devang Patel <devang.patel@gmail.com> writes:

>> * DW_AT_GNU_OD_cmd - it seems strange for this to be defined in terms
>> of text highlighting.  Why have a separate code here for "dead
>> code" instead of just marking a text region and having a new _msg
>> value meaning "dead code"?

Devang> In the case of "dead code" we could use _msg. However, _cmd is
Devang> available to trigger some actions in tools that use this
Devang> information. If we let our imaginations run wild then for
Devang> example, lead developer towards __restrict documentation
Devang> (i.e. launch lang. standard doc in one window and open
Devang> particular page).

I agree, interconnections like the above are cool and useful.  But
this approach seems weird, because it is asking compiler maintainers
to decide whether a given result is a message or an action.

I think it would be more natural for the compiler to say what did or
did not happen, and then to have the IDE, or whatever, apply
interpretation to the record of the facts.  I.e., no message/action
distinction.

>> What are "action trails"?

Devang> For example, Loop A is unrolled. It is not a parameter
Devang> manipulation hint, it is not a limitation and it is not a hint
Devang> to developers. It is just a report of what optimizer did. This
Devang> is default category.

Ok.  Why are these things stored in bits and not as a enumeration of
possible values?  Usually the use of bits implies that combinations of
them are valid, but here it sounds as though the values are actually
independent.

>> How would the user find out what parameter is referred to by a
>> parameter manipulation hint?  I don't see where this is recorded.

Devang> This should be encoded in msg text.

You mean it is implicit in the _msg value?  If so, then the linkage
between a given _msg value and a particular option ought to be
documented.  I realize this can't be done in a DWARF spec, but it at
least needs to be done in GCC somewhere... it would be helpful to have
this spelled out.

Tom

Re: [RFC] Optimization Diary

[Devang Patel]

Tom Tromey wrote:
>>>>>> "Devang" == Devang Patel <devang.patel@gmail.com> writes:
>>>>>>             
>
>   
>>> * DW_AT_GNU_OD_cmd - it seems strange for this to be defined in terms
>>> of text highlighting.  Why have a separate code here for "dead
>>> code" instead of just marking a text region and having a new _msg
>>> value meaning "dead code"?
>>>       
>
> Devang> In the case of "dead code" we could use _msg. However, _cmd is
> Devang> available to trigger some actions in tools that use this
> Devang> information. If we let our imaginations run wild then for
> Devang> example, lead developer towards __restrict documentation
> Devang> (i.e. launch lang. standard doc in one window and open
> Devang> particular page).
>
> I agree, interconnections like the above are cool and useful.  But
> this approach seems weird, because it is asking compiler maintainers
> to decide whether a given result is a message or an action.
>
> I think it would be more natural for the compiler to say what did or
> did not happen, and then to have the IDE, or whatever, apply
> interpretation to the record of the facts.  I.e., no message/action
> distinction.
>   
I understand what you are saying. I will give this more thought and
get back to you.
>   
>>> What are "action trails"?
>>>       
>
> Devang> For example, Loop A is unrolled. It is not a parameter
> Devang> manipulation hint, it is not a limitation and it is not a hint
> Devang> to developers. It is just a report of what optimizer did. This
> Devang> is default category.
>
> Ok.  Why are these things stored in bits and not as a enumeration of
> possible values?  Usually the use of bits implies that combinations of
> them are valid, but here it sounds as though the values are actually
> independent.
>   
Exactly, combinations are valid. For example,
- when loop is vectorized using peeling to handle unknown alignment
  then it is - action performed plus hint (possible use of explicit 
alignment
  attributes)
- When loop is vectorized using peeling to handle known
  misalignment then it is only action performed.
- When loop is not vectorized because of alignment issues then it is a
  hint as well as lack of action
- When loop is not vectorized because multiple misalignments then it is
  a lack of action plus limitation plus hint

It is possible that this is too much info and in general it may not be
applicable to other optimizations, but this is starting point for my thought
process.
>   
>>> How would the user find out what parameter is referred to by a
>>> parameter manipulation hint?  I don't see where this is recorded.
>>>       
>
> Devang> This should be encoded in msg text.
>
> You mean it is implicit in the _msg value?  If so, then the linkage
> between a given _msg value and a particular option ought to be
> documented.  I realize this can't be done in a DWARF spec, but it at
> least needs to be done in GCC somewhere... it would be helpful to have
> this spelled out.
>   
Yes. I have not spent time to catalog all interesting messages (and I'll
need help here). I admit, I have concentrated mostly from vectorizer
point of view.

-
Devang

Re: [RFC] Optimization Diary

[Devang Patel]

Tom Tromey wrote:
>
> Devang> In the case of "dead code" we could use _msg. However, _cmd is
> Devang> available to trigger some actions in tools that use this
> Devang> information. If we let our imaginations run wild then for
> Devang> example, lead developer towards __restrict documentation
> Devang> (i.e. launch lang. standard doc in one window and open
> Devang> particular page).
>
> I agree, interconnections like the above are cool and useful.  But
> this approach seems weird, because it is asking compiler maintainers
> to decide whether a given result is a message or an action.
>
> I think it would be more natural for the compiler to say what did or
> did not happen, and then to have the IDE, or whatever, apply
> interpretation to the record of the facts.  I.e., no message/action
> distinction.
>   


Since messages are represented using a number, how about using
one category bit to identify command message vs display message ?
Command message is a message where tools, reading opt diary,
take perform some actions.


-
Devang

Re: [RFC] Optimization Diary

[Tom Tromey]

>>>>> "Devang" == Devang Patel <devang.patel@gmail.com> writes:

Devang> Since messages are represented using a number, how about using
Devang> one category bit to identify command message vs display message ?
Devang> Command message is a message where tools, reading opt diary,
Devang> take perform some actions.

I still don't see how gcc maintainers would know to make this
distinction.  Perhaps I'm misunderstanding the distinction between
command and display.

Tom

Re: [RFC] Optimization Diary

[Devang Patel]

Tom Tromey wrote:
>>>>>> "Devang" == Devang Patel <devang.patel@gmail.com> writes:
>>>>>>             
>
> Devang> Since messages are represented using a number, how about using
> Devang> one category bit to identify command message vs display message ?
> Devang> Command message is a message where tools, reading opt diary,
> Devang> take perform some actions.
>
> I still don't see how gcc maintainers would know to make this
> distinction.  Perhaps I'm misunderstanding the distinction between
> command and display.
>   

for (i=0; i<4; i++)
{
  C[i] = A[i] + C[i+3];
}

Auto vectorizer emits three messages.
1) This loop is not vectorized because of data dependency.
2) Highlight C[i]
3) Highlight C[i+3]

Here vectorizer knows that 2) and 3) are commands and 1) is display message.

-
Devang

Re: [RFC] Optimization Diary

[Paul Brook]

> > I still don't see how gcc maintainers would know to make this
> > distinction.  Perhaps I'm misunderstanding the distinction between
> > command and display.
>
> for (i=0; i<4; i++)
> {
>   C[i] = A[i] + C[i+3];
> }
>
> Auto vectorizer emits three messages.
> 1) This loop is not vectorized because of data dependency.
> 2) Highlight C[i]
> 3) Highlight C[i+3]
>
> Here vectorizer knows that 2) and 3) are commands and 1) is display
> message.

I don't buy this. Whether things are highlighted or comments added seems like 
something that the consumer should decide. ie. the compiler generates:

1) {points at for loop} Loop not vectorized because of data dependency
1a) {points at C[i]} Conflicting data element
1b) {points at C[i+3]} Conflicting data element

Paul

Re: [RFC] Optimization Diary

[Devang Patel]

Tom Tromey wrote:
> * Why put the optimization diary into the object file?
>   Why not just have -Wdiary and print it along with all the warnings?
>   (I'm sure there's an answer to this, it would just be nice if it
>   were in the document...)
>   
These are not warnings and they should not cause build failures
when -Werror is used, hence warnings are not suitable medium to
communicate this info.

However, GCC provides hints along with warnings and errors. But they
all reside in build log. While doing performance analysis, build log
may not be available hence it is required to have it on disk somewhere.

And text format is not suitable because of two reasons:
1) It is verbose. Try -opt_report in ICC.
2) This info is consumed by other tools (e.g. IDE, performance analyzer).
It makes sense for a tool like Shark to use dwarf reader to get this info
then parse raw text output.

So, if
1) we need to keep this info on disk and available with final binary
and 2) we use binary format to encode this info)
then dwarf in object file is a natural selection.

Command line developer can use extended dwarf reader to get the text
messages.

-
Devang

Re: [RFC] Optimization Diary

[Andrew Pinski]

> These are not warnings and they should not cause build failures
> when -Werror is used, hence warnings are not suitable medium to
> communicate this info.

There is a third type of diagnostic in GCC which gets not much
use at all.  It is called note.  It might be interesting to use that instead
of saying there is no way to cause no build failures with warnings.

Thanks,
Andrew Pinski

Re: [RFC] Optimization Diary

[Devang Patel]

Andrew Pinski wrote:
>> These are not warnings and they should not cause build failures
>> when -Werror is used, hence warnings are not suitable medium to
>> communicate this info.
>>     
>
> There is a third type of diagnostic in GCC which gets not much
> use at all.  It is called note.  It might be interesting to use that instead
> of saying there is no way to cause no build failures with warnings.
>   
That's what I meant when I said "hints" ...

"However, GCC provides (notes) along with warnings and errors. But they
all reside in build log. While doing performance analysis, build log
may not be available hence it is required to have it on disk somewhere. "

-
Devang

Re: [RFC] Optimization Diary

[Andrew Pinski]

> 
> Andrew Pinski wrote:
> >> These are not warnings and they should not cause build failures
> >> when -Werror is used, hence warnings are not suitable medium to
> >> communicate this info.
> >>     
> >
> > There is a third type of diagnostic in GCC which gets not much
> > use at all.  It is called note.  It might be interesting to use that instead
> > of saying there is no way to cause no build failures with warnings.
> >   
> That's what I meant when I said "hints" ...
> 
> "However, GCC provides (notes) along with warnings and errors. But they
> all reside in build log. While doing performance analysis, build log
> may not be available hence it is required to have it on disk somewhere. "

If you are doing performance analysis the build log better be able to look
at to make sure you are building with the correct options unless you trust
the IDEs (which I and many other people don't).

-- Pinski

Re: [RFC] Optimization Diary

[Devang Patel]

Andrew Pinski wrote:
>> Andrew Pinski wrote:
>>     
>>>> These are not warnings and they should not cause build failures
>>>> when -Werror is used, hence warnings are not suitable medium to
>>>> communicate this info.
>>>>     
>>>>         
>>> There is a third type of diagnostic in GCC which gets not much
>>> use at all.  It is called note.  It might be interesting to use that instead
>>> of saying there is no way to cause no build failures with warnings.
>>>   
>>>       
>> That's what I meant when I said "hints" ...
>>
>> "However, GCC provides (notes) along with warnings and errors. But they
>> all reside in build log. While doing performance analysis, build log
>> may not be available hence it is required to have it on disk somewhere. "
>>     
>
> If you are doing performance analysis the build log better be able to look
> at to make sure you are building with the correct options unless you trust
> the IDEs (which I and many other people don't).
>   
Two things.

First this is not about IDE vs no IDE. Lets take one example.
We, here at Apple, do not use IDE to build GCC. However we routinely
install pre built compiler package on various machines and do compile
time performance analysis using Shark. When Shark points me to a code
hot spot, I want to know what optimizer was thinking about it.

Second, optimization diary is not about what options are enabled and
disabled. Compiler should not invoke any particular optimization pass
just to add optimization diary entry. Its is a diary of optimization passes
that are active.

-
Devang

[ Interestingly, there is a long standing request, here at Apple, to list
  command line options in object file (even when optimization is not used).
  One of our intern tried to put them in STABS string. It may be a good
  idea to use DWARF in that case also. However it is orthogonal to
  optimization diary. It is a good small project, if someone is 
interested. ]

Re: [RFC] Optimization Diary

[Gabriel Dos Reis]

Devang Patel <devang.patel@gmail.com> writes:

| [ Interestingly, there is a long standing request, here at Apple, to list
|   command line options in object file (even when optimization is not used).
|   One of our intern tried to put them in STABS string. It may be a good
|   idea to use DWARF in that case also. However it is orthogonal to
|   optimization diary. It is a good small project, if someone is
| interested. ]

I was under the impression that it was sort tkane care of by some
patches from CodeSourcery.  Though, it is possible I may have dreamted.

-- Gaby

Re: [RFC] Optimization Diary

[Daniel Jacobowitz]

On Tue, Jun 06, 2006 at 03:47:59PM -0500, Gabriel Dos Reis wrote:
> Devang Patel <devang.patel@gmail.com> writes:
> 
> | [ Interestingly, there is a long standing request, here at Apple, to list
> |   command line options in object file (even when optimization is not used).
> |   One of our intern tried to put them in STABS string. It may be a good
> |   idea to use DWARF in that case also. However it is orthogonal to
> |   optimization diary. It is a good small project, if someone is
> | interested. ]
> 
> I was under the impression that it was sort tkane care of by some
> patches from CodeSourcery.  Though, it is possible I may have dreamted.

Nope, it was Nick.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Optimization Diary

[Gabriel Dos Reis]

On Tue, 6 Jun 2006, Daniel Jacobowitz wrote:

| On Tue, Jun 06, 2006 at 03:47:59PM -0500, Gabriel Dos Reis wrote:
| > Devang Patel <devang.patel@gmail.com> writes:
| >
| > | [ Interestingly, there is a long standing request, here at Apple, to list
| > |   command line options in object file (even when optimization is not used).
| > |   One of our intern tried to put them in STABS string. It may be a good
| > |   idea to use DWARF in that case also. However it is orthogonal to
| > |   optimization diary. It is a good small project, if someone is
| > | interested. ]
| >
| > I was under the impression that it was sort tkane care of by some
| > patches from CodeSourcery.  Though, it is possible I may have dreamted.
|
| Nope, it was Nick.

Thanks for the correction.  My apologies to Nick.

-- Gaby

Re: [RFC] Optimization Diary

[Ramana Radhakrishnan]

Hi Devang,

<some part snipped>
> -
> Devang
> 
> [ Interestingly, there is a long standing request, here at Apple, to list
>   command line options in object file (even when optimization is not used).
>   One of our intern tried to put them in STABS string. It may be a good
>   idea to use DWARF in that case also. However it is orthogonal to
>   optimization diary. It is a good small project, if someone is 
> interested. ]
> 


Is this what you want ? This doesn't use DWARF but just has a separate
section options section which contains all the options passed. 

http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01119.html

It seems to be awaiting review. 

cheers
Ramana

Re: [RFC] Optimization Diary

[Devang Patel]

>
>> Is this what you want ? 

yes :)

Thanks,
-
Devang

Re: [RFC] Optimization Diary

[Gabriel Dos Reis]

Devang Patel <devang.patel@gmail.com> writes:

| Tom Tromey wrote:
| > * Why put the optimization diary into the object file?
| >   Why not just have -Wdiary and print it along with all the warnings?
| >   (I'm sure there's an answer to this, it would just be nice if it
| >   were in the document...)
| >
| These are not warnings and they should not cause build failures
| when -Werror is used, hence warnings are not suitable medium to
| communicate this info.

The diagnostic machinery has the "note" diagnostic kind; and the
diagnostic can have customized prefixes, e.g. "note: ".

-- Gaby

Re: [RFC] Optimization Diary

[Tom Tromey]

>>>>> "Devang" == Devang Patel <devang.patel@gmail.com> writes:

Tom> * Why put the optimization diary into the object file?

[...]

Devang> 2) This info is consumed by other tools (e.g. IDE, performance
Devang> analyzer).  It makes sense for a tool like Shark to use dwarf
Devang> reader to get this info then parse raw text output.

Thanks, this makes sense to me.  I suggest adding this to your
document as rationale.

Tom

Re: [RFC] Optimization Diary

[Devang Patel]

Tom Tromey wrote:
>>>>>> "Devang" == Devang Patel <devang.patel@gmail.com> writes:
>>>>>>             
>
> Tom> * Why put the optimization diary into the object file?
>
> [...]
>
> Devang> 2) This info is consumed by other tools (e.g. IDE, performance
> Devang> analyzer).  It makes sense for a tool like Shark to use dwarf
> Devang> reader to get this info then parse raw text output.
>
> Thanks, this makes sense to me.  I suggest adding this to your
> document as rationale.
>   

OK.

-
Devang

Re: [RFC] Optimization Diary

[Daniel Berlin]

Tom Tromey wrote:
>>>>>> "Devang" == Devang Patel <dpatel@apple.com> writes:
> 
> Devang> This version removes internal radar numbers and replaces s/
> Devang> DW_AT_APPLE.../DW_AT_GNU...
> 
> 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
> dumb :-).
> 
> I do have a few questions and concerns.
> 
>
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.

If you are worried about space usage, you needn't be.  Any sane compiler
will place the strings in the .debug_str section, and they will only
appear once (ld even does cross-object-file string section merging here).

If you are worried about the strings not being canonical from version to
version, then just enforce them being canonical at the compiler level.

The easiest way there is to just put a comment before the function or
whatever that generates the string saying it shouldn't be changed
between versions.

Re: [RFC] Optimization Diary

[Tom Tromey]

>>>>> "Dan" == Daniel Berlin <dberlin@dberlin.org> writes:

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

One reason to prefer the numerical approach is that it makes
localization of the user interface simpler.

Dan> The easiest way there is to just put a comment before the function or
Dan> whatever that generates the string saying it shouldn't be changed
Dan> between versions.

We would also have to constrain the messages not to have any
printf-style substitutions, since that would be an i18n disaster.

Otherwise, yeah, I was wondering about this myself.

Tom

Re: [RFC] Optimization Diary

[Geoffrey Keating]

Daniel Berlin <dberlin@dberlin.org> writes:

> Tom Tromey wrote:
> >>>>>> "Devang" == Devang Patel <dpatel@apple.com> writes:
> > 
> > Devang> This version removes internal radar numbers and replaces s/
> > Devang> DW_AT_APPLE.../DW_AT_GNU...
> > 
> > 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
> > dumb :-).
> > 
> > I do have a few questions and concerns.
> > 
> >
> 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
table of possible strings somewhere, so you might as well save space
by not putting it in every object file.

Re: [RFC] Optimization Diary

[Daniel Berlin]

Geoffrey Keating wrote:
> Daniel Berlin <dberlin@dberlin.org> writes:
> 
>> Tom Tromey wrote:
>>>>>>>> "Devang" == Devang Patel <dpatel@apple.com> writes:
>>> Devang> This version removes internal radar numbers and replaces s/
>>> Devang> DW_AT_APPLE.../DW_AT_GNU...
>>>
>>> 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
>>> dumb :-).
>>>
>>> I do have a few questions and concerns.
>>>
>>>
>> 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
> table of possible strings somewhere, so you might as well save space
> by not putting it in every object file.

I believe this is a red herring.
We control the debug output machinery generating this, and can simply
tell it to only deal in one language.

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.

Re: [RFC] Optimization Diary

[Andrew Pinski]

> 
> 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.

In the same way numbering warning messages is a bad idea (yes ICC and a couple
other compilers do but we should not).

-- Pinski

Re: [RFC] Optimization Diary

[Geoffrey Keating]

[-- Attachment #1: Type: text/plain, Size: 1575 bytes --]


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

> Geoffrey Keating wrote:
>> Daniel Berlin <dberlin@dberlin.org> writes:
>>
>>> Tom Tromey wrote:
>>>>>>>>> "Devang" == Devang Patel <dpatel@apple.com> writes:
>>>> Devang> This version removes internal radar numbers and replaces s/
>>>> Devang> DW_AT_APPLE.../DW_AT_GNU...
>>>>
>>>> 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
>>>> dumb :-).
>>>>
>>>> I do have a few questions and concerns.
>>>>
>>>>
>>> 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
>> table of possible strings somewhere, so you might as well save space
>> by not putting it in every object file.
>
> I believe this is a red herring.
> We control the debug output machinery generating this, and can simply
> tell it to only deal in one language.

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".

> 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...

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2408 bytes --]

Re: [RFC] Optimization Diary

[Daniel Berlin]

Geoffrey Keating wrote:
> On 06/06/2006, at 4:58 PM, Daniel Berlin wrote:
> 
>> Geoffrey Keating wrote:
>>> Daniel Berlin <dberlin@dberlin.org> writes:
>>>
>>>> Tom Tromey wrote:
>>>>>>>>>> "Devang" == Devang Patel <dpatel@apple.com> writes:
>>>>> Devang> This version removes internal radar numbers and replaces s/
>>>>> Devang> DW_AT_APPLE.../DW_AT_GNU...
>>>>>
>>>>> 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
>>>>> dumb :-).
>>>>>
>>>>> I do have a few questions and concerns.
>>>>>
>>>>>
>>>> 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
>>> table of possible strings somewhere, so you might as well save space
>>> by not putting it in every object file.
>> I believe this is a red herring.
>> We control the debug output machinery generating this, and can simply
>> tell it to only deal in one language.
> 
> 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.

>> 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...

I have a very hard time believing that compiling and outputting messages
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.

You can disagree. I'm just trying to tell you this has almost zero hope
of ever being standardized if you keep it as a bunch of numbers.

It also has almost zero hope of working over multiple compiler versions,
being future proof in general, and not having other compiler vendors
fight over message number namespace.

--Dan

Re: [RFC] Optimization Diary

[Geoffrey Keating]

[-- Attachment #1: Type: text/plain, Size: 2667 bytes --]


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 <dberlin@dberlin.org> writes:
>>>>
>>>>> Tom Tromey wrote:
>>>>>>>>>>> "Devang" == Devang Patel <dpatel@apple.com> writes:
>>>>>> Devang> This version removes internal radar numbers and  
>>>>>> replaces s/
>>>>>> Devang> DW_AT_APPLE.../DW_AT_GNU...
>>>>>>
>>>>>> 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
>>>>>> dumb :-).
>>>>>>
>>>>>> I do have a few questions and concerns.
>>>>>>
>>>>>>
>>>>> 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
>>>> table of possible strings somewhere, so you might as well save  
>>>> space
>>>> by not putting it in every object file.
>>> I believe this is a red herring.
>>> We control the debug output machinery generating this, and can  
>>> simply
>>> tell it to only deal in one language.
>>
>> 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...
>
> I have a very hard time believing that compiling and outputting  
> messages
> 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.

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.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2408 bytes --]

Re: [RFC] Optimization Diary

[Andrew Pinski]

> 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.

Just output in English and let the IDE or the other tools translate it.

-- Pinski

Re: [RFC] Optimization Diary

[Geoffrey Keating]

[-- Attachment #1: Type: text/plain, Size: 707 bytes --]


On 06/06/2006, at 5:20 PM, Andrew Pinski wrote:

>> 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.
>
> Just output in English and let the IDE or the other tools translate  
> it.

What's the difference between that and just outputting a number and  
letting the IDE or other tool translate it?  Either way, you're going  
to need a fixed set of strings or numbers to translate.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2408 bytes --]

Re: [RFC] Optimization Diary

[Andrew Pinski]

> 
> 
> --Apple-Mail-9--465959030
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain;
> 	charset=US-ASCII;
> 	delsp=yes;
> 	format=flowed
> 
> 
> On 06/06/2006, at 5:20 PM, Andrew Pinski wrote:
> 
> >> 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.
> >
> > Just output in English and let the IDE or the other tools translate  
> > it.
> 
> What's the difference between that and just outputting a number and  
> letting the IDE or other tool translate it?  Either way, you're going  
> to need a fixed set of strings or numbers to translate.

Say I want to add a new one, I have to go through a committee with the
number system while with a string I don't.

-- Pinski

Re: [RFC] Optimization Diary

[Geoffrey Keating]

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]


On 06/06/2006, at 5:25 PM, Andrew Pinski wrote:

>> On 06/06/2006, at 5:20 PM, Andrew Pinski wrote:
>>
>>>> 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.
>>>
>>> Just output in English and let the IDE or the other tools translate
>>> it.
>>
>> What's the difference between that and just outputting a number and
>> letting the IDE or other tool translate it?  Either way, you're going
>> to need a fixed set of strings or numbers to translate.
>
> Say I want to add a new one, I have to go through a committee with the
> number system while with a string I don't.

I don't see how making it a string makes this different.  Either your  
new string will be a standard string or it won't.  Either your new  
number will be a standard number or it won't.  If you want it to be  
standard, you have to go through the committee.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2408 bytes --]

Re: [RFC] Optimization Diary

[Andrew Pinski]

> I don't see how making it a string makes this different.  Either your  
> new string will be a standard string or it won't.  Either your new  
> number will be a standard number or it won't.  If you want it to be  
> standard, you have to go through the committee.

I don't understand why it has to be a "standard" string/message.
Yes there could be some base set of messages.  Also with the number
system, you have to update the IDE when news ones get added while
with the message way you don't unless you want to translate it to
another language.

-- Pinski

Re: [RFC] Optimization Diary

[Daniel Jacobowitz]

On Tue, Jun 06, 2006 at 05:36:33PM -0700, Geoffrey Keating wrote:
> I don't see how making it a string makes this different.  Either your  
> new string will be a standard string or it won't.  Either your new  
> number will be a standard number or it won't.  If you want it to be  
> standard, you have to go through the committee.

In practice, using string identifiers does make conflicts less likely.
It's also easier for a vendor to pick a unique prefix and be confident
that Apple isn't going to assign some other meaning to
"csl-inline-bart".

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Optimization Diary

[Devang Patel]

Daniel Jacobowitz wrote:
> On Tue, Jun 06, 2006 at 05:36:33PM -0700, Geoffrey Keating wrote:
>   
>> I don't see how making it a string makes this different.  Either your  
>> new string will be a standard string or it won't.  Either your new  
>> number will be a standard number or it won't.  If you want it to be  
>> standard, you have to go through the committee.
>>     
>
> In practice, using string identifiers does make conflicts less likely.
> It's also easier for a vendor to pick a unique prefix and be confident
> that Apple isn't going to assign some other meaning to
> "csl-inline-bart".

We can allocate space in numbering for vendor extensions. 

-
Devang

Re: [RFC] Optimization Diary

[Andrew Pinski]

On Jun 6, 2006, at 9:49 PM, Devang Patel wrote:
> We can allocate space in numbering for vendor extensions.

What happens when you compile two sources with two different  
compilers and they
use the same number for vendor extension?  You just end up with weird  
results
in the IDE or performance analysis program.
Also what happens after you fill up the vendor extension range?

Also what happens when you change your compiler but not IDE, but you  
don't
want to update the IDE?  Like for an example I compile myself GCC 5.0.0
which adds LTO and you get more data (that was not implemented in  
4.2.0).
I personally don't have access to Xcode sources to get an updated  
version
or Shark code (unless you are going to release them into open source  
which
I doubt Apple wants that).  I want all the new features of GCC 5.0.0  
and the
new optimization diary support and there is no way to get that  
support with
numbers.  With messages I get all this support for free and you don't  
need
a mapping in the IDE at all (unless you want translation).

Oh, by the way does Xcode provide a way to change the language which the
error messages are outputted because I cannot find one?

-- Pinski

Re: [RFC] Optimization Diary

[Devang Patel]

Andrew Pinski wrote:
>
> On Jun 6, 2006, at 9:49 PM, Devang Patel wrote:
>> We can allocate space in numbering for vendor extensions.
>
> What happens when you compile two sources with two different compilers 
> and they
> use the same number for vendor extension?  

What happens when another compiler uses 0x4104 TAG value for
something else and GCC uses it for DW_TAG_GNU_BINCL ?
> You just end up with weird results
> in the IDE or performance analysis program.
> Also what happens after you fill up the vendor extension range?
What happens when vendor extension range for TAGs and Attributes are full ?

> Also what happens when you change your compiler but not IDE, but you 
> don't
> want to update the IDE?
What happens when GCC adds new DWARF extension but you do not want
to update GDB ?

-
Devang

Re: [RFC] Optimization Diary

[Andrew Pinski]

On Jun 6, 2006, at 10:34 PM, Devang Patel wrote:

> Andrew Pinski wrote:
>>
>> On Jun 6, 2006, at 9:49 PM, Devang Patel wrote:
>>> We can allocate space in numbering for vendor extensions.
>>
>> What happens when you compile two sources with two different  
>> compilers and they
>> use the same number for vendor extension?
>
> What happens when another compiler uses 0x4104 TAG value for
> something else and GCC uses it for DW_TAG_GNU_BINCL ?

Not my fault and not really related because we are creating a new  
standard and
don't want to repeat this mistake, messages don't have this issue.

>> You just end up with weird results
>> in the IDE or performance analysis program.
>> Also what happens after you fill up the vendor extension range?
> What happens when vendor extension range for TAGs and Attributes  
> are full ?

Who cares, we are trying making something which is useful and not  
making something which
is going to be limited.

>> Also what happens when you change your compiler but not IDE, but  
>> you don't
>> want to update the IDE?
> What happens when GCC adds new DWARF extension but you do not want
> to update GDB ?

Again, we are trying to make something useful and extendable. If you  
don't
care about usefulness and extendibility then go ahead and use numbers.

Having the message gets rid of having duplicated code in each program  
that processes
the numbers, you have the message right away without doing extra work.

You really should listen to Daniel Berlin if you ever want this to be  
officially
part of the dwarf2 standard.  Remember he is part of the committee  
there.

You get extendibility for free and no need to change the IDE every  
thing you want to
add a new diary entry.  What more do you want something for free or  
something which
limits the use?  If you want something which is limited you may as  
well then just not
use dwarf2 and instead write out a text file.

-- Pinski

Re: [RFC] Optimization Diary

[Devang Patel]

Andrew Pinski wrote:
>
> On Jun 6, 2006, at 10:34 PM, Devang Patel wrote:
>
>> Andrew Pinski wrote:
>>>
>>> On Jun 6, 2006, at 9:49 PM, Devang Patel wrote:
>>>> We can allocate space in numbering for vendor extensions.
>>>
>>> What happens when you compile two sources with two different 
>>> compilers and they
>>> use the same number for vendor extension?
>>
>> What happens when another compiler uses 0x4104 TAG value for
>> something else and GCC uses it for DW_TAG_GNU_BINCL ?
>
> Not my fault 

Read your question, my reply question and your answer.
> and not really related because we are creating a new standard and
> don't want to repeat this mistake, messages don't have this issue.
>
>>> You just end up with weird results
>>> in the IDE or performance analysis program.
>>> Also what happens after you fill up the vendor extension range?
>> What happens when vendor extension range for TAGs and Attributes are 
>> full ?
>
> Who cares,

Again, read your question, my reply question and your answer.
Tell me, why should n't I laugh ? :) :)

Is it constructive (and appropriate? but hey I'm DWARF newbie myself) to 
declare
DWARF standard limited and full of mistakes ?
> we are trying making something which is useful and not making 
> something which
> is going to be limited.
>
>>> Also what happens when you change your compiler but not IDE, but you 
>>> don't
>>> want to update the IDE?
>> What happens when GCC adds new DWARF extension but you do not want
>> to update GDB ?
>
> Again, we are trying to make something useful and extendable. If you 
> don't
> care about usefulness and extendibility then go ahead and use numbers.

Read proposal again. There is one thing in proposal that allows to 
handle similar
situation for diary messages in nicer way.
>
> Having the message gets rid of having duplicated code in each program 
> that processes
> the numbers, you have the message right away without doing extra work.
Do you ever wonder why errno is number and not error string ?
>
> You really should listen to Daniel Berlin if you ever want this to be 
> officially
> part of the dwarf2 standard.  Remember he is part of the committee there.

Well, I've hunch that if he has to cast vote then he will do it based on 
technical
merits and he will not cast vote based on his or someone else's initial 
position.

-
Devang

Re: [RFC] Optimization Diary

[Andrew Pinski]

On Jun 7, 2006, at 10:10 AM, Devang Patel wrote:

> Is it constructive (and appropriate? but hey I'm DWARF newbie  
> myself) to declare
> DWARF standard limited and full of mistakes ?

No, I am saying that dwarf2 is supposed to be stable and adding stuff  
is not likely
going to happen that often unlike optimizations.

> Read proposal again. There is one thing in proposal that allows to  
> handle similar
> situation for diary messages in nicer way.

What look funny instead of looking right?

> Do you ever wonder why errno is number and not error string ?

And how many times new error numbers get added?  Almost never,  
compared to adding
a new optimization which can happen any time now.

Look at the problem this way, if it does not change that much often  
then yes it should
be a number, otherwise a message string is better.


Can we have standard numbers for file names now, then?

Thanks,
Andrew Pinski

Re: [RFC] Optimization Diary

[Devang Patel]

Andrew Pinski wrote:
>
> On Jun 7, 2006, at 10:10 AM, Devang Patel wrote:
>
>> Is it constructive (and appropriate? but hey I'm DWARF newbie myself) 
>> to declare
>> DWARF standard limited and full of mistakes ?
>
> No, I am saying that dwarf2 is supposed to be stable and adding stuff 
> is not likely
> going to happen that often unlike optimizations.
No, you said it has limitations and it is mistake to allow vendor 
extensions in DWARF.
>
>> Read proposal again. There is one thing in proposal that allows to 
>> handle similar
>> situation for diary messages in nicer way.
>
> What look funny instead of looking right?

Optimization diary has its own version number. When new messages
are included version number is updated. This allows its consumer to
take appropriate action and not choke. Appropriate action may be, ignore
entire diary or ignore unknown messages or something else...
>
>> Do you ever wonder why errno is number and not error string ?
>
> And how many times new error numbers get added?  Almost never, 
> compared to adding
> a new optimization which can happen any time now.
>
> Look at the problem this way, if it does not change that much often 
> then yes it should
> be a number, otherwise a message string is better.
>
>
> Can we have standard numbers for file names now, then?

OK, I opened the wrong window and this has no relation to this 
discussion. Lets close
and stay focused :)

Since you chose to not continue discuss regarding your three questions 
(overlapping
numbers, no space in extension range and tools mismatch), I guess I've
answered all your questions.

-
Devang

Re: [RFC] Optimization Diary

[Andrew Pinski]

> No, you said it has limitations and it is mistake to allow vendor 
> extensions in DWARF.
My exact words were:
Not my fault and not really related because we are creating a new standard and
don't want to repeat this mistake, messages don't have this issue.

I was not trying to imply dwarf2 was mistaken to use numbers.


> >
> >> Read proposal again. There is one thing in proposal that allows to 
> >> handle similar
> >> situation for diary messages in nicer way.
> >
> > What look funny instead of looking right?
> 
> Optimization diary has its own version number. When new messages
> are included version number is updated. This allows its consumer to
> take appropriate action and not choke. Appropriate action may be, ignore
> entire diary or ignore unknown messages or something else...

Version numbers are sometimes counter productive.

So you don't want stuff for free fine, then go implement what ever you want
with out thinking about adding new optimziations.

> >
> >> Do you ever wonder why errno is number and not error string ?
> >
> > And how many times new error numbers get added?  Almost never, 
> > compared to adding
> > a new optimization which can happen any time now.
> >
> > Look at the problem this way, if it does not change that much often 
> > then yes it should
> > be a number, otherwise a message string is better.
> >
> >
> > Can we have standard numbers for file names now, then?
> 
> OK, I opened the wrong window and this has no relation to this 
> discussion. Lets close and stay focused :)

How is it not related, you asked about error numbers staying the same
and I just mention they are not changing that often, even dwarf2 does not
change that often.

> Since you chose to not continue discuss regarding your three questions 
> (overlapping
> numbers, no space in extension range and tools mismatch), I guess I've
> answered all your questions.

Overlapping numbers and tool mismatch are instaintly solved with messages
and there is no problems with space in the extension range because you don't
need a range.

The other issue that numbers come with is are the corresponding messages
sharable between compilers and compiler versions?

Like say, call location was not inlined because number of times this function
can be inlined was hit.  Shouldn't we provide this information to the user instead
of saying it was not inlined (with no reason).  Yes this is extension range but
what happens when two compilers says the same thing but a third cannot say that but
instead says "because 10 inlines is too much for the function".


Or with the vectorizer in mind, we have to version this loop for alignment because
we can only prove the alignment is 4 bytes.  Isn't that better than just saying the
loop was version because alignment cannot be proved to be 16bytes?

-- Pinski

Re: [RFC] Optimization Diary

[Devang Patel]

Andrew Pinski wrote:
>> No, you said it has limitations and it is mistake to allow vendor 
>> extensions in DWARF.
>>     
> My exact words were:
> Not my fault and not really related because we are creating a new standard and
> don't want to repeat this mistake, messages don't have this issue.
>
> I was not trying to imply dwarf2 was mistaken to use numbers.
>   

"... don't want to repeat **this** mistake ...". What are referring here ?

>>>> Read proposal again. There is one thing in proposal that allows to 
>>>> handle similar
>>>> situation for diary messages in nicer way.
>>>>         
>>> What look funny instead of looking right?
>>>       
>> Optimization diary has its own version number. When new messages
>> are included version number is updated. This allows its consumer to
>> take appropriate action and not choke. Appropriate action may be, ignore
>> entire diary or ignore unknown messages or something else...
>>     
>
> Version numbers are sometimes counter productive.
>   

How ?

>     Since you chose to not continue discuss regarding your three questions 
>     (overlapping
>     numbers, no space in extension range and tools mismatch), I guess I've
>     answered all your questions.
>         
>
>
> Overlapping numbers and tool mismatch are instaintly solved with messages
> and there is no problems with space in the extension range because you don't
> need a range.
>   

And string does not answer localization issue, however for numbers at least
there is one precedent to follow.
> The other issue that numbers come with is are the corresponding messages
> sharable between compilers and compiler versions?
>   

Again it is a not a unsolvable issue.

Plus strings do not play nice with command messages.

> Like say, call location was not inlined because number of times this function
> can be inlined was hit.  Shouldn't we provide this information to the user instead
> of saying it was not inlined (with no reason).  Yes this is extension range but
> what happens when two compilers says the same thing but a third cannot say that but
> instead says "because 10 inlines is too much for the function".
>   

So ? What are you trying to say here ?
>
> Or with the vectorizer in mind, we have to version this loop for alignment because
> we can only prove the alignment is 4 bytes.  Isn't that better than just saying the
> loop was version because alignment cannot be proved to be 16bytes?
>   

So, what are you trying to say here ?

-
Devang

Re: [RFC] Optimization Diary

[Daniel Jacobowitz]

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.  But with string duplicate elimination - your linker can
do that, I hope - it's only larger by a trivial amount.


-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Optimization Diary

[Devang Patel]

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.  

I agree.
> 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.  But with string duplicate elimination - your linker can
> do that, I hope - it's only larger by a trivial amount.
>   

I am not too tied with initial positions of this proposal (see my
discussions with Tom) however in this case trade offs are not
favoring one or other with wide margin. Plus if you see my last
message to Tom in this thread, we are talking about using
_msg to say  "highlight this text". I think it makes more sense
to not use strings in this situation.

Anyway, time to focus discussion on other open questions.

1) Steven B. off line suggested that we need some mechanism to
identify compiler phase. I agree, it is useful to filter messages.
What do other people think about it ?

2) Do we need to enforce source location ordering in diary messages ?

-
Devang

Re: [RFC] Optimization Diary

[Geoffrey Keating]

[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]


On 07/06/2006, at 11:33 AM, 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".

Apparently, "strings" means lots of different things to different  
people.  Everyone hopes that a string will solve their perceived  
problem without realising that everyone else is hoping for something  
incompatible.

> 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.  But with string duplicate elimination - your linker can
> do that, I hope - it's only larger by a trivial amount.

It's important to realise that when we complain about debug size, we  
mean in .o files.  Our linker doesn't copy any DWARF debug  
information to its product.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2408 bytes --]

Re: [RFC] Optimization Diary

[Michael Matz]

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.

Re: [RFC] Optimization Diary

[Andrew Pinski]

> 
> And string does not answer localization issue, however for numbers at least
> there is one precedent to follow.

And strings have precedent for localization also, just look into how
GCC's error messages are done.  Or even any of the Mac OS X programs
which does all localization based on strings.  I don't see this as a problem.

> > The other issue that numbers come with is are the corresponding messages
> > sharable between compilers and compiler versions?
> >   
> 
> Again it is a not a unsolvable issue.
> 
> Plus strings do not play nice with command messages.

What do you mean by play nice.  variable names play nice so it has to play nice already

> 
> > Like say, call location was not inlined because number of times this function
> > can be inlined was hit.  Shouldn't we provide this information to the user instead
> > of saying it was not inlined (with no reason).  Yes this is extension range but
> > what happens when two compilers says the same thing but a third cannot say that but
> > instead says "because 10 inlines is too much for the function".
> >   
> 
> So ? What are you trying to say here ?

That we cannot make a set of numbers that match up every single possibility that
could exist even currently.


> >
> > Or with the vectorizer in mind, we have to version this loop for alignment because
> > we can only prove the alignment is 4 bytes.  Isn't that better than just saying the
> > loop was version because alignment cannot be proved to be 16bytes?
> >   
> 
> So, what are you trying to say here ?

Likewise, I was trying to give an example of why numbers just fail.

-- Pinski

Re: [RFC] Optimization Diary

[Richard Earnshaw]

On Wed, 2006-06-07 at 01:36, Geoffrey Keating wrote:
> On 06/06/2006, at 5:25 PM, Andrew Pinski wrote:
> 
> >> On 06/06/2006, at 5:20 PM, Andrew Pinski wrote:
> >>
> >>>> 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.
> >>>
> >>> Just output in English and let the IDE or the other tools translate
> >>> it.
> >>
> >> What's the difference between that and just outputting a number and
> >> letting the IDE or other tool translate it?  Either way, you're going
> >> to need a fixed set of strings or numbers to translate.
> >
> > Say I want to add a new one, I have to go through a committee with the
> > number system while with a string I don't.
> 
> I don't see how making it a string makes this different.  Either your  
> new string will be a standard string or it won't.  Either your new  
> number will be a standard number or it won't.  If you want it to be  
> standard, you have to go through the committee.

If I'm using a french translation and I see 'Variable optimized away' I
might get irritated but I can try to translate it.  If I see
<translation-of>'Unrecognized optimization code 33' I've got no chance.

Using string codes allows a more relaxed propagation model for the
translations (provided we don't keep tweaking the strings).

R.

Re: [RFC] Optimization Diary

[Tom Tromey]

>>>>> "Dan" == Daniel Berlin <dberlin@dberlin.org> writes:

Dan> You still need to be able to display the message for each number in all
Dan> the languages you want, so it's going to be stored somewhere, you
Dan> haven't solved the problem, just moved it completely to the consumer.

Usually I'm not a fan of using numbers instead of strings.  But in
this particular case I think it does make sense.

One reason is that numbers are compiler-independent.  This means that
the IDE can provide its preferred text for each message and this will
work regardless of what compiler is in use.

With strings you either need to enumerate all possible strings or you
need access to the compiler's message catalog -- but either of these
is hard to do in a compiler-independent way.

Dan> I have a very hard time believing that compiling and outputting messages
Dan> in one language, and having someone who can't read those messages
Dan> optimize and profile your application in another language, is a
Dan> significant enough use case to be worried about.

Yes, I agree that this is scenario probably does not occur often.
Nevertheless I think we should aim for maximum usability -- it is a
bad idea in general to design something knowing about a losing i18n
case... usage frequencies change.

Dan> It also has almost zero hope of working over multiple compiler versions,
Dan> being future proof in general, and not having other compiler vendors
Dan> fight over message number namespace.

The maintenance issue is a major one.  This document definitely needs
to address this, and not just in some theoretical way.  Otherwise,
chaos ensues.  I'm sure we've all seen the consequences here plenty of
times, enough to insist on a solution.

Tom

Re: [RFC] Optimization Diary

[Devang Patel]

Tom Tromey wrote:
> Dan> It also has almost zero hope of working over multiple compiler versions,
> Dan> being future proof in general, and not having other compiler vendors
> Dan> fight over message number namespace.
>
> The maintenance issue is a major one.  This document definitely needs
> to address this, and not just in some theoretical way.  Otherwise,
> chaos ensues.  I'm sure we've all seen the consequences here plenty of
> times, enough to insist on a solution

Yes. When I update this proposal, I'll include more details. However, I
do not have extensive experience crafting such specs so any guidance
is very helpful.

One thing I am not very clear about myself in this discussion. Is 
optimization
diary a life time GNU extension ? Or Is it suitable enough to prepare a
proposal for inclusion in future DWARF version ?

-
Devang