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

Hubert Tong via cfe-dev cfe-dev at lists.llvm.org
Sat Apr 25 19:01:03 PDT 2020


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];


>
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200425/83eccc69/attachment.html>


More information about the cfe-dev mailing list