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: ia64 tls support


> On Sun, May 26, 2002 at 01:54:33PM +0200, Jan Hubicka wrote:
> > I see that it does not scale very well for large programs, having 3MBs
> > per thread overhead for GCC, for Mozilla it can be even more.  What I
> > was thinking about is to create just pointer per function and allocate
> > table when function is invoked first time.  Then the static overhead
> > will be number_of_function*4 that should be considerably fewer + one
> > conditional in function profile + function call at cold path.
> > 
> > Does this sound sane?
> 
> Not really.  I don't see how you're going to coordinate the threads.

I meant that at clone we will create array of NULLs for each function in
TLS and when then at function call we will check her entry and if it is
NULL, we will simply malloc the block for counters. At thread's exit we
just free the allocated blocks.
> 
> > Concerning the second alternative - having atomic/thread safe increments
> > on counters, can you show me example how this can be done on i386?
> 
> 	lock addl $1, mem
> 	lock adcl $0, mem+4
> 
> Recall that you don't care about having the entire 64-bit result
> stable until the end of the program.  It's just that you don't
> want to lose any increments.

Hmm, I got to that idea, but somehow managed to convience myself that
lock does not work in userland, that is of course false.
I've just checked, it increases the overhead about 4 times on
uniprocessor celeron machine.  That can be acceptable...

Honza
> 
> 
> r~


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