This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Optimization Diary
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