This is the mail archive of the 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: Mainline merge part 14 - profiler improvements


> > 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.
> You also tried to make libcalls to the inline functions/macros
> defined in that header.  It's not going to work.

Where? I only call them from libgcc2.c, which IMHO should be OK.

> > Is it possible to use the atomic instructions in all targets?
> No, but I'm of a mind to say "too bad" to those that don't.
> > Even on i386 it seems to be problem because we need 64bit arithmetics.
> cmpxchg8 for i586 and better.
> If we really feel like it, we can implement a libgcc entry point
> that handles targets that just have test-and-set spinlocks.

I don't think putting additional instructions, one of them jump, to every edge
is a good idea concerning the performance. I know that the solution I have
chosen is clumsy, so if we find better, I will be glad to rework it.

> > The memory usage is not really that big, as the tables are fairly
> > small even for large programs.
> Define fairly small.

I believe Honza defined it, but it is (number of edges - number of blocks) *
sizeof(counter). In my implementation it must be multiplied by number of
running threads.


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