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 11:56:55PM +0200, Jan Hubicka wrote:
> > 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.
> 
> Oh, I see.  And since one zero-initialized tls variable per
> function gets the first part done for free, that does make
> the scheme somewhat more attractive.  However...
> 
> > I've just checked, it increases the overhead about 4 times on
> > uniprocessor celeron machine.  That can be acceptable...
> 
> Indeed.
> 
> FWIW, I measure 2x and 3.6x on p3 and p4xeon respectively.

OK, thinking about it, I guess all I need is to add named pattern for
this containing unspec.  One unfortunate thing is that I've hoped to get
induction variable transformations done after profiling, so the counters
inside loops gets recognized as IVs and lifted out of the loop, that
won't work if we don't allow then to live in pseudos, but the thread
safe profiling can be opitonal for start and of the overhead gets
important factor, we can implement the more complicated alternative.

Just curious, does the RISCy machines has similar feature?  They usually
don't have load-modify-store isntructions, but they can have something
as synchronization primitive.  I need to fill gaps in my knowledge
here...

Honza
> 
> 
> r~


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