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