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


On Mon, Jun 09, 2003 at 12:53:05PM +0200, Jan Hubicka wrote:
> > Zdenek Dvorak wrote:
> > >Hello,
> > >
> > >there are several optimizations that may benefit from some knowledge
> > >about values of expressions in the program, e.g specialization of
> > >operations/standard functions, prefetching, decision heuristics for
> > >some optimizations, etc.  We have implemented and tested some of them
> > >on hammer-3_3-branch; I think they are ready to be merged to mainline
> > >now.
> > >
> > >This patch brings in the means to instrument the program to obtain
> > >data about values of expressions.
> > 
> > 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
> confusion.
> > 
> > BTW, is there a less cryptic name than 'vpt'? I can't see in the patch
> > any description of how these parts all hang together -- some comment
> > in vpt.h would be nice.
> > 
> > >	* 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.

Perhaps -fprofile implying both, -fprofile-arcs, -fprofile-values, and
-fuse-profile-data?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


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