[AIX] LLVM data layout is incorrect unless overridden by clang

[workingjubilee]

Frontends for LLVM that offer support for the powerpc64-ibm-aix target but do not manually implement the Clang patch that overrides the data layout, specifically here, are using an incorrect data layout. This has resulted in hundreds of hours being wasted on trying to identify bugs due to incompatible layouts in those compilers, partially because of further conflation between the notion of alignment and "preferred" alignment, and the presence of a cryptically-worded "power alignment" rule in IBM's documentation. This problem affects rustc, but it likely also affects other frontends for LLVM, like flang.

As far as I can tell, the so-called "power alignment" rule, if Clang's implementation is correct (and you don't care that much about trying to reason about the details of C++ object and subobject layouts), merely is a rule that the compiler should align the type on the stack using the "preferred" alignment. It has no other effect. Even if this happens to affect parameter passing, and is thus required in that case for FFI correctness, then it is not a noteworthy distinction: other ABIs have far more "interesting" ad-hoc on-stack alignment exceptions. Otherwise, compilers should not need to be told that they may wish to overalign things for their internal stack layouts if it seems performance would benefit, as that would hopefully be obvious.

This should be fixed by

• ceasing to have an ad-hoc override in clang for the data layout
• spelling out the target data layout in LLVM so other frontends can use it

[workingjubilee]

I believe this is the place to update in order to make LLVM inherently know the correct data layout for AIX:

llvm-project/llvm/lib/Target/PowerPC/PPCTargetMachine.cpp

Line 154 in 31c37a4

static std::string getDataLayoutString(const Triple &T) {

Of course, it is possible that the current implementation in clang is also incorrect (i.e. may be incompatible with gcc), but at least then, clang, flang, rustc, and whoever else would agree in their incorrectness.

[workingjubilee]

To elaborate slightly further, so that everything is incredibly clear here as to why this is the correct fix? Many frontends simply obtain the data layout by invoking LLVMCreateTargetMachine, then going through LLVMCreateDataLayout, or else implementing the same in C++ code. This allows them to bypass specific knowledge of the target and automatically agree with clang on many points, only needing to know what string they would use to obtain the target to begin with.

[llvmbot]

@llvm/issue-subscribers-backend-powerpc

Author: Jubilee (workingjubilee)

Frontends for LLVM that offer support for the powerpc64-ibm-aix target but do not manually implement [the Clang patch that overrides the data layout](https://github.com/llvm/llvm-project/commit/05ad8e942996f36cc694478542ccd84aa5bbb80f), specifically [here](https://github.com/llvm/llvm-project/blob/d66af9c69b6960ad5f903cc6c0db99395dace6af/clang/lib/Basic/Targets/PPC.h#L406-L413), are using an incorrect data layout. This has resulted in hundreds of hours being wasted on trying to identify bugs due to incompatible layouts in those compilers, partially because of further conflation between the notion of alignment and "preferred" alignment, and the presence of a cryptically-worded "power alignment" rule in IBM's documentation. This problem affects rustc, but it likely also affects other frontends for LLVM, like flang.

As far as I can tell, the so-called "power alignment" rule, if Clang's implementation is correct, merely is a rule that the compiler should align the type on the stack using the "preferred" alignment. It has no other effect. Even if this happens to affect parameter passing, and is thus required in that case for FFI correctness, then it is not a noteworthy distinction: other ABIs have far more "interesting" ad-hoc on-stack alignment exceptions. Otherwise, compilers should not need to be told that they may wish to overalign things for their internal stack layouts if it seems performance would benefit, as that would hopefully be obvious.

This should be fixed by

• ceasing to have an ad-hoc override in clang for the data layout
• spelling out the target data layout in LLVM so other frontends can use it

[efriedma-quic]

Can you clarify what change to the datalayout string you're proposing? Just appending -f64:32:64? That seems reasonable.

The way clang target handling works, the code you're calling "ad-hoc" has to stay: clang does not derive the size/alignment of types from the LLVM DataLayout. The size/alignment/format of basic types needs to be explicitly specified separately from the datalayout, even if it looks redundant at first glance.

[workingjubilee]

Can you clarify what change to the datalayout string you're proposing? Just appending -f64:32:64? That seems reasonable.

Correct.

The way clang target handling works, the code you're calling "ad-hoc" has to stay: clang does not derive the size/alignment of types from the LLVM DataLayout. The size/alignment/format of basic types needs to be explicitly specified separately from the datalayout, even if it looks redundant at first glance.

...Huh.

Okay, that's weird. I kiiinda think clang should work the way I said so that clang actually tests what everyone else is expecting to be correct to derive things from, but I'm fully willing to believe that is also somehow wrong. If clang and LLVM both will have their own sets of expectations, then maybe they should just check that their expectations match in some cases.