This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Mainline merge part 14 - profiler improvements
Hello.
> > 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.
Zdenek