In support of IBM's efforts to produce a viable C and C++ LLVM compiler for AIX (ref: RFC at http://lists.llvm.org/pipermail/llvm-dev/2019-February/130175.html), this patch adds customizations to the CMake files in order to properly invoke the host toolchain for the build on AIX. Additional changes to enable a successful build will follow.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
| llvm/cmake/modules/HandleLLVMOptions.cmake | ||
|---|---|---|
| 138 | I'm interested in why you choose bigtoc linker option over using large code model? From the little I understand about the bigtoc option it seems that large code model would be the preferable solution when expecting to have a toc that is a lot bigger then 64K. | |
| llvm/cmake/modules/HandleLLVMOptions.cmake | ||
|---|---|---|
| 138 | -fPIC is already specified. Even if the code is generated using the large code model, TOC overflow is a hard error for the linker unless if -bbigtoc is specified. On linking, the XL compiler specifies -bbigtoc to the linker in response -qpic=large. You can see this for yourself if you compile the following with -q64 -qpic=large and link with only -q64: #define x2A( BASE ) BASE ## a, BASE ## b
#define x2B( BASE ) x2A(BASE ## a), x2A(BASE ## b)
#define x2C( BASE ) x2B(BASE ## a), x2B(BASE ## b)
#define x2D( BASE ) x2C(BASE ## a), x2C(BASE ## b)
#define x2E( BASE ) x2D(BASE ## a), x2D(BASE ## b)
#define x2F( BASE ) x2E(BASE ## a), x2E(BASE ## b)
#define x2G( BASE ) x2F(BASE ## a), x2F(BASE ## b)
#define x2H( BASE ) x2G(BASE ## a), x2G(BASE ## b)
#define x2I( BASE ) x2H(BASE ## a), x2H(BASE ## b)
#define x2J( BASE ) x2I(BASE ## a), x2I(BASE ## b)
#define x2K( BASE ) x2J(BASE ## a), x2J(BASE ## b)
#define x2KA( BASE ) x2K(BASE ## a), x2K(BASE ## b)
#define x2KB( BASE ) x2KA(BASE ## a), x2KA(BASE ## b)
int x2KB( x );
int main(void) { x2KB( ++x ); } | |
| llvm/cmake/modules/HandleLLVMOptions.cmake | ||
|---|---|---|
| 138 | Okay, it seems -fPIC does not enable the large code model for GCC on AIX (but does for the new XL compilers). -mcmodel=large should be added for GCC; however, the linker option remains necessary. | |
| llvm/include/llvm/Config/abi-breaking.h.cmake | ||
|---|---|---|
| 37–41 | Is this correct though? I would expect non-hidden visibility checks to break things. | |
| llvm/include/llvm/Config/abi-breaking.h.cmake | ||
|---|---|---|
| 37–41 | My understanding is yes: AIX does not export by default. Maybe a comment in the code is warranted? | |
| llvm/cmake/modules/HandleLLVMOptions.cmake | ||
|---|---|---|
| 138 | I had a look at the example. You are right, the code XL generates does need the link-option. The code generated for main uses the large code model with R_TOCU/R_TOCL relocations, but the compiler inserts a bunch of code that still uses small code model R_TOC relocations (namely ._start, ._thread_init, and ._C_runtime_startup). The code gcc generates for the example links just fine without the extra option as they only use large code model relocations. We need to add -mcmodel=large for gcc, and only use -bbigtoc for XL. | |
Comment Actions
Address review comments:
- Add comment regarding correctness of not applying a visibility attribute when using GCC on AIX.
- Apply -mcmodel=large for GCC on AIX, and use -Wl,-bbigtoc for XL (on AIX) only.
| llvm/cmake/modules/HandleLLVMOptions.cmake | ||
|---|---|---|
| 139 | For this and other instances of STREQUAL "XL", we should use MATCHES "XL" so that "XLClang" is also matched. See https://gitlab.kitware.com/cmake/cmake/merge_requests/2921. | |
Comment Actions
I believe all comments on this have been addressed. This LGTM. I'll probably commit this on Monday.
| llvm/include/llvm/Config/abi-breaking.h.cmake | ||
|---|---|---|
| 37 | __GNU__ is not the macro we want to check here (it checks for GNU Hurd, i.e., the OS). The intention is to check for GCC. I am not sure if there is a better way to check for "real" GCC as opposed to the GCC-compatible compilers other than to filter for each of the known compatible compilers that do not suffer from the same limitation as GCC. | |
Comment Actions
Address review comments:
- Check __GNUC__ for GCC instead of __GNU__ and exclude CLANG which also sets macro __GNUC__.
Comment Actions
Why do you exclude clang? I would expect LLVM at this point to not support visibility attributes on XCOFF either?
Comment Actions
The scope of this patch is to enable use of GCC and IBM XL compilers on AIX as build compilers for LLVM. The desired semantic of the line in question is to disable the use of the visibility attribute for GCC. The condition on __clang__ is meant to prevent gobbling up non-GCC compilers in the check for __GNUC__. The consideration of whether Clang should itself be exempted from the use of the visibility attribute on AIX seems premature.
I'm interested in why you choose bigtoc linker option over using large code model? From the little I understand about the bigtoc option it seems that large code model would be the preferable solution when expecting to have a toc that is a lot bigger then 64K.