This is the mail archive of the 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: [PATCH] Value profile based optimizations, part 1

Jan Hubicka wrote:

Although you have vpt.h and vpt.c, you have inserted code into profile.c
that has intimate knowledge of vpt. The vpt files are small. Would it
not be more sensible to either
1) put all the vpt stuff into profile.h & profile.c
2) put all the vpt stuff into vpt.h & vpt.c
my inclination is for #1?

vpt stuff is going to grow and I would be against putting all that into profile.c.

profile.c/h contains the routines to actually profile stuff, while vpt
will contain optimizations that does use the data.  That split seems to
be pretty clean to me (everything in profile.c so far is about analysis)
Perhaps the interface and/or comment can be clarified to avoid the
ok, makes sense. Zdenek, there needs to be some explanetory comments
about the big picture.

* flags.h (flag_value_histograms): Declare.

why not flag_value_profile? you've called this value profiling after all? Histogram is the implementation technique, value profiling is the desired outcome. A user is more likely to understand what the value-profiling means.

-fvalue-profile would be fine with me.
Perhaps we can also think about sanyfing the naming if -profile-arcs
-fbranch-probabilities pair.  Perhaps by adding aliased -fprofile-gen
-fprofile-use that is easier to remember.
makes sense too.


Nathan Sidwell    ::   ::     CodeSourcery LLC
         The voices in my head said this was stupid too    ::

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