Tom Tromey wrote:
"Devang" == Devang Patel <[EMAIL PROTECTED]> 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
