[cfe-dev] [RFC] Adding AIX power alignment rule in clang front end

[James Y Knight via cfe-dev]

On Sat, Apr 25, 2020 at 10:01 PM Hubert Tong via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Fri, Apr 24, 2020 at 3:55 PM Eli Friedman via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> Assuming I’m understanding the rule correctly, it doesn’t actually affect
>> “alignment” of the type in the sense we would normally understand it.  A
>> struct with a double as the first member can be stored at an address with
>> four-byte alignment.  The rule only involves inserting extra padding at the
>> end of the struct. In particular, from the way you’re describing the rule,
>> I think the special alignment rule isn’t supposed to affect the result of
>> _Alignof.  Does that seem right?
>>
> The reference implementations on AIX indicate that the result of _Alignof
> is affected.
>
> C:
> typedef struct A { double x; int y; } A;
> extern char x[_Alignof(A)];
> extern char x[8];
>
> C++:
> struct A {
>   A(const A &);
>   double x; int y;
> };
> struct B : A { int z; };
>
> extern char x[sizeof(B)];
> extern char x[16];
>
> extern char y[alignof(A)];
> extern char y[8];
>

Unfortunately, this is invalid behavior. _Alignof/alignof must return the
*required* alignment for a type. Given that per your previous example:
struct C {
  int n;
  struct A a;
};
would place the type A at an offset of 4, alignof(A) cannot correctly
return greater than 4.

You also need to ensure that the alignment values that Clang specifies when
creating memory operations in LLVM IR are correct, and not higher than they
should be, which they will be, if you've set the alignment of the structure
too high.

I believe the best option would be to modify the struct layout code to
round up the size as Eli suggests, and then modify
ASTContext::getPreferredTypeAlign so that variables of these types get an
increased alignment. This function is also used to implement the
non-standard GCC extension "__alignof__(T)", which unlike alignof/_Alignof,
returns the "preferred" alignment of T, rather than the minimum alignment.

(BTW, the name "Preferred alignment" in this context is somewhat of a
misnomer. It makes it sound like this "preferred" alignment is not part of
the ABI. But it actually is, as implemented in clang today, because it's
used as the assumed alignment of an extern (or common or comdat) global
variable of that type, not just when defining a variable. I suspect Clang
doesn't actually get this correct for some of the other non-i386 ABIs which
have underaligned doubles.)

Given that, do you actually need to store anything in the RecordLayout at
>> all?
>>
> Does the new information change your analysis or it is still worthwhile to
> internally treat the alignment as the lower value (and add special code to
> introduce the padding-for-preferred-alignment)?
>
>
>> Also, probably worth checking the layout for a testcase like the
>> following, to check the interaction between the extra padding and the
>> nvsize:
>> [ ... ]
>>
> Thanks; done above. The padding does not occur within the nvsize. I guess
> you also mean that we should check this against the new implementation as
> well.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200426/06f8670f/attachment-0001.html>