Re: [RFC] Memcpy/memset profiling infrastructure

[Jan Hubicka <hubicka at ucw dot cz>]

> 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...

Honza
> 
> Richard.