Re: Mainline merge part 14 - profiler improvements

[Jan Hubicka <jh at suse dot cz>]

> On Mon, May 06, 2002 at 03:58:51PM +0200, Jan Hubicka wrote:
> >   function.o : function.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) flags.h \
> >      function.h $(EXPR_H) libfuncs.h $(REGS_H) hard-reg-set.h \
> >      insn-config.h $(RECOG_H) output.h toplev.h except.h hash.h $(GGC_H) \
> > -    $(TM_P_H) langhooks.h
> > +    $(TM_P_H) langhooks.h gthr.h
> 
> gthr.h is a target header.  You cannot include it in a host object file
> at all.  This seems a fairly fundamental problem with the threading code.
> Therefore I'm not going to review any of it.

I guess it is used only to determine whether some threading is available.  We
may simply emit the thread functions aleways or make this configure parameter.
> 
> Also, does it not make more sense to generate atomic add instructions
> instead of expanding the amount of memory used possibly 1000 fold?

Is it possible to use the atomic instructions in all targets?   Even on i386 it
seems to be problem because we need 64bit arithmetics.
We can use some simple locking scheme, but that looks like performance overkill.
The memory usage is not really that big, as the tables are fairly small even for
large programs.
Generally less than number of basic blocks in the functions for non-dense CFGs.
> 
> > !       char_array_type = build_array_type (char_type_node, integer_type_node);
> > !       string_type = build_pointer_type (char_array_type);
> 
> integer_type_node is incorrect here.  You should use build_index_type 
> to create the exact bounds of the array.  It is therefore senseless
> to create a common type for this unless there are lots of arrays with
> the same length.
> 
> See fix_string_type for how this should be handled.

I will fix these problems shortly.  I am not very familiar with the
trees, so I was unable to fix that.
> Other notes:
> 
>   * Lots of lines exceed 80 columns.
I was trying to catch this..  I will re-check.
>   * If you're changing the file format, you need to document it.
>     Yes, I know the previous format was undocumented, but that's
>     a mistake we shouldn't repeat.
It is documented (there is gcov.texi change or at least should be in
the patch)

Honza
> 
> 
> r~