[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: CFP (Call for Participation) Debian PPC64



On Sun, Nov 16, 2003 at 09:41:58PM -0500, Albert Cahalan wrote:
> Using 16-byte stack alignment? More?

We've had 16 byte stack alignment on ppc64 forever.

> Keeping .text in the low 2 GB? Other stuff?

-maddr32 does the text and static data in -2G..2G thing.  Not in
 mainline gcc because the powerpc maintainers didn't like it.  Anton is
 messing around with it in the kernel at the moment, but results so far
 are discouraging.  We're probably hitting some cache problems due to
 mapping the kernel at -2G as well as 0xc << 60.  Then again, it might
 be that David Edelsohn was right all along, and -maddr32 doesn't give
 us any performance increase.

> Keeping anything in a 48-bit range?
> (One less opcode than full 64-bit)

No.  ppc64 loads 64 bit addresses from the TOC.  We don't build up 64
bit addresses from multiple insns each setting 16 bits at a time.

> That TOC?

CVS ld supports generation of multiple TOCs and stubs to adjust r2 as
necessary.  -mminimal-toc shouldn't be needed except in extreme cases.

In some ways the TOC is a good thing.  Think of it as a compiler
generated GOT.  Then realize that the compiler can do better than the
linker in placing entries for good cache performance.  On other Linux
architectures, ld generates the GOT via a hash table traversal, which
means entries are fairly well randomized.

> Still using "funtion pointers" that aren't?

I'm not sure what you mean here.

> Anything left to improve?

Plenty.  For starters, I'd like to get rid of those pesky dot symbols.
ie. A ".foo" symbol defined as well as a "foo" symbol for each function
"foo".

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre



Reply to: