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: [RFC] Memcpy/memset profiling infrastructure


> > On 10/26/06, Jan Hubicka <jh@suse.cz> wrote:
> > >Hi,
> > >I am sending this patch as RFC because it would need at least adding 
> > >mechanizm to hide internal builtin functions from user.
> > >
> > >What I am shooting for is to annotate histogram information during 
> > >profiling
> > >about expected size and alignment of memcpy/memsetted blocks to be used 
> > >later
> > >at RTL expansion time.  I do have patch that allows chosing of proper 
> > >memcpy
> > >algorithm (i. e. rep/movs, loop, unrolled loop or libcall) in x86 backend 
> > >based
> > >on this info.
> > >
> > >The problem lies in annotating the histogram with the call.  What I do is
> > >simply adding variants builtin_memcpy_hints/builtin_memset_hints that do 
> > >accept
> > >those extra information as additional arguments.  This is very 
> > >non-intrusive to
> > >rest of middle-end but do have disadvantage that it works only for explicit
> > >memset/memcpy calls (ie not for structure assignments, where alignment 
> > >would be
> > >still interesting, but not as much as in the generic case) and it woiuld be
> > >moderately painful to add similar profiling to other builtins (my profiling
> > >code, not included in patch, only memset/memcpy/bzero is profiled) because 
> > >new
> > >alternatives needs to be introduced.
> > >
> > >I've disucssed this briefly on GCC summit with Rth and we didn't found 
> > >better
> > >way around.  Possibly if we get rid of TER, it would be more convenient to
> > >attach the profiles to statements and use it at exansion time, but even 
> > >that
> > >has problems, since updating the histograms would need some care.
> > >
> > >If no one comes with good idea, I will add the bits to avoid the function 
> > >from
> > >being user visible (how this is best doable BTW?) and send updated patch at
> > >begining of next week.
> > 
> > I agree that this is the most sensible way of doing it - did you
> > verify that statement
> > annotations for the call do not survive until expansion?  We at least have 
> > stuff
> > stored for value profiling there (but it is used before expansion in a
> > tree optimizer).
> 
> The annotations are thrown away earlier, but you are correct that it
> probably can be fixed.  Thinking it over, TER probably won't mangle it
> too badly since the statemnt containing the memcpy is not inserted into
> other statement because of the function argument saving problems.
> 
> We would need to some way to maintain the information about current
> statement (perhaps by global variable) that is currently thrown away as
> expansion is expression based. Plus we would have to be considerably
> more cureful about not throwing away the information from annotations at
> code movement/duplication and such so we don't confuse the histograms.
> We would win extra flexibility about what is profiled...

Thinking about it more, I see fewer problems in this approach than I saw
few months back, so I will break out the target bits to separate patch
and will try to implement this vairant as incremental patch so we can at
least give it a try (I am not sure how painful maintaining the
histograms would be, to be honest)

Honza


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