A. Pool Allocation under PowerPC (Mac)

Hello,

Is PA working on the macintosh already?

I am asking because I found this in the source code:

/// Wants8ByteAlignment - FIXME: this is a complete hack for X86 right now.

Thanks

Ricardo wrote:

Hello,

Is PA working on the macintosh already?

Although we may not have run it on MacOS X recently, I believe that it should work. We've run it on several architectures and operating systems, including SparcV9/Solaris.

If you find that PA doesn't compile or work on MacOS X, please file a bug report (http://llvm.cs.uiuc.edu/bugs/) so that we can fix it.

I am asking because I found this in the source code:

/// Wants8ByteAlignment - FIXME: this is a complete hack for X86 right now.

I'm not sure what this means, but I don't believe that it means that it only works on x86. It might just fiddle with alignments to get better performance out of the x86.

Thanks

_______________________________________________
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev

-- John T.

John,

Thanks for the information. That comment in the source code confused me and I wanted to be sure
that the installation of all the LLVM framework in the macintosh for testing the pool allocation
was not going to be done in vain.

The LLVM documentation states that gcc 3.4x is necessary for compiling the LLVM. On the other
hand, Xtools 1.5 for Mac includes only gcc 3.3 and Xtools 2.0 includes gcc 4.0. Do I need to
download and build the gcc 3.4 source code? Do you have any installation guide for LLVM under Mac
OS X?

Also, in the release notes, it is stated that for the Power PC:

"Code generation is supported for 32-bit ABI only"

If that is the case then, isn't the code generated for Power PC going to use 64 bit pointers? If
so, I suppose that the Mac platform is not going to benefit too much from the Automatic Pointer
Compression. Am I correct?

Thanks

Ricardo wrote:

John,

Thanks for the information. That comment in the source code confused me and I wanted to be sure
that the installation of all the LLVM framework in the macintosh for testing the pool allocation
was not going to be done in vain.

The LLVM documentation states that gcc 3.4x is necessary for compiling the LLVM. On the other
hand, Xtools 1.5 for Mac includes only gcc 3.3 and Xtools 2.0 includes gcc 4.0. Do I need to
download and build the gcc 3.4 source code? Do you have any installation guide for LLVM under Mac
OS X?

Do you know where you read that in the documentation?

LLVM (and hence, llvm-poolalloc) will build with various versions of GCC 3.3.x and GCC 3.4.x. Looking at the Getting Started Guide, I don't see any known problems with GCC 3.3 listed.

You should try to compile with GCC 3.3 as it will probably work. If you hit a GCC crash, then you will probably need to upgrade to GCC 3.4.x.

BTW, the llvm-gcc code is based off of GCC 3.4 (more accurately, GCC 3.4 when it was in development).

Also, in the release notes, it is stated that for the Power PC:

"Code generation is supported for 32-bit ABI only"

If that is the case then, isn't the code generated for Power PC going to use 64 bit pointers? If
so, I suppose that the Mac platform is not going to benefit too much from the Automatic Pointer
Compression. Am I correct?

If I understand correctly, code generated by our PowerPC backend will generate 32 bit code. Hence, all of the pointers will be 32 bits.

You can probably generate 64 bit PowerPC code by using the LLVM C backend (llc -march=c) and then compile the generated C code with GCC to 64 bit PowerPC code. You might have to pass some options to llvm-gcc as well so that it knows that it should compile C longs and pointers as 64 bit entities.

However, even if you generate 64 bit LLVM code, you still have the problem that MacOS X is not fully 64 bit (from what I hear). So even then, pointer compression might not be as useful on MacOS X as it is on other 64 bit platforms (where the OS provides more complete 64 bit APIs).

-- John T.

John,

Thanks for the information. That comment in the source code confused me and I wanted to be sure
that the installation of all the LLVM framework in the macintosh for testing the pool allocation
was not going to be done in vain.

That hacked function (Want8ByteAlignment) is effectively disabled if you use the -poolalloc-disable-alignopt option. This will force all poolalloc allocations to be 8-byte aligned.

I believe malloc() on MacOS actually uses 16-byte alignment but I think that is to ensure that data used by AltiVec code is aligned propertly. If you need 16-byte alignment for any reason, you should be able to fix that in the function getRecommendedAlignment() in llvm-poolalloc/lib/PoolAllocate/Heuristics.cpp.

"Code generation is supported for 32-bit ABI only"

If that is the case then, isn't the code generated for Power PC going to use 64 bit pointers? If
so, I suppose that the Mac platform is not going to benefit too much from the Automatic Pointer
Compression. Am I correct?

Pointer compression only compresses 64 to 32-bit pointers. I should also warn that (based on very recent experience) this transform is very limited at the moment and will silently break a lot of programs, example, most codes that use function pointers.

Pool allocation, however, is much more stable and works on both 32 and 64-bit targets.

--Vikram