This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Optimization Diary


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]