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

Xiangling Liao via cfe-dev cfe-dev at lists.llvm.org
Mon May 11 10:26:42 PDT 2020


Hi,
Thank you for all of your involvement and suggestion. Based on our
discussion in this thread, a new patch has been posted on the Phabricator:
https://reviews.llvm.org/D79719.

Regards,
Xiangling

On Fri, Apr 24, 2020 at 9:20 AM Xiangling Liao <xiangxdh at gmail.com> wrote:

> Currently we are trying to implement AIX special alignment rule on the top
> of Itanium ABI in Clang. On AIX,  in aggregates, the first member of
> double/long double is aligned according to its natural alignment value;
> subsequent double/long double of the aggregate are aligned on 4-byte
> boundaries.
>
>
>
> This rule is recursive. It applies all the way to the inner most nested
> members. An example is as the following:
>
>
>
> struct D {
>         double d;
>         int i;
> };
>
>
>
> struct IntFirst {
>         int i;
>         struct D d;
> };
>
>
>
> The size of struct D is 16, class alignment is 8;
>
> The size of struct IntFirst is 20, class alignment is 4;
>
>
>
> So our current idea is to have an alignment field to record nested struct
> info and pass the special alignment value all the way back to the ourter
> most aggregate.
>
>
>
> And based on this idea, there are two possible ways.
>
>
>
> 1.
>
> The first one is that we introduced a new field in class *ASTRecordLayout*
>
> Called `*AIXOffsetAlignment*`  which represents the special AIX alignment
> for the object that
>
> contains floating-point member or sub-member. This is for AIX-ABI only.
>
>
>
> The proposed change has been put on Phabricator under review:
> https://reviews.llvm.org/D78563
>
>
>
> *Pros:*
>
> - The design is cleaner. It is clear that such field is for AIX and it
> does not affect any other target
>
>    in terms of functionality.
>
>
>
> *Cons:*
>
> - All other targets using ItaniumRecordLayoutBuilder will also have to pay
> the price to keep
>
>    updating this `*AIXOffsetAlignment` *along the common code path by
> using *`UpdateAlignment*`.
>
>
>
> 2.
>
> The second possible way we have in mind is to overload the usage of
> current Microsoft-ABI only alignment field *`RequiredAlignment*` and
> rename it to `*TargetSpecialAlignment*` instead of the above first way to
> create a new alignment field.
>
> This alignment field will function the same in Itanium ABI part for AIX.
> Meanwhile, because the current `RequiredAlignment` is only used in MS code,
> renaming will not affect MS code path functionally.
>
>
>
> *Pro:*
>
> - Class ASTRecordLayout does not need to construct one more field
> `AIXOffsetAlignment` compared to the method one.
>
> - Instead of having each target add new fields for their special alignment
> rules, we could have one field that handles all the potential alignment
> differences for every target.
>
>
>
> *Cons:*
>
> -  Still, all other targets using ItaniumRecordLayoutBuilder will also
> have to pay the price to
>
>    keep updating this `TargetSpecialAlignment` along the common code path
> by using
>
>    `UpdateAlignment`.
>
> -  By overloading the usage, it may create confusion when more targets try
> to utilize it in the
>
>    future.
>
> -  The degree of willingness of sharing this current MS-only alignment
> field is unknown.
>
>
>
>
>
> I would like to see how people think about the above two ways. Which one
> is better? Any concerns about either one? Or any other ideas to suggest?
>
>
>
> Please let me know if there are any questions about my current proposal
> and design. Your feedback is appreciated.
>
>
>
> Regards,
>
>
>
> Xiangling Liao
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200511/626caed5/attachment-0001.html>


More information about the cfe-dev mailing list