This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Value profile based optimizations, part 1
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Jan Hubicka <jh at suse dot cz>
- Cc: Nathan Sidwell <nathan at codesourcery dot com>,Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>,gcc-patches at gcc dot gnu dot org
- Date: Mon, 9 Jun 2003 09:30:29 -0400
- Subject: Re: [PATCH] Value profile based optimizations, part 1
- References: <3EABD519.firstname.lastname@example.org> <20030427163514.GA5895@atrey.karlin.mff.cuni.cz> <3EAE8A13.email@example.com> <20030429153741.GA20897@atrey.karlin.mff.cuni.cz> <3EB3BA9E.firstname.lastname@example.org> <20030503215839.GA7007@atrey.karlin.mff.cuni.cz> <3EB51BF4.email@example.com> <20030608204856.GA23446@atrey.karlin.mff.cuni.cz> <3EE45249.firstname.lastname@example.org> <20030609105305.GN31246@kam.mff.cuni.cz>
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/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
> > 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
MontaVista Software Debian GNU/Linux Developer