Re: [RFC] Optimization Diary

[Devang Patel <devang dot patel at gmail dot com>]

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