This is an archive of the discontinued LLVM Phabricator instance.

MSVC AArch64 ABI: Homogeneous aggregates
ClosedPublic

Authored by dblaikie on Sep 26 2022, 6:48 PM.

Details

Summary

Fixes:
Protected members, HFA: https://godbolt.org/z/zqdK7vdKc
Private members, HFA: https://godbolt.org/z/zqdK7vdKc
Non-empty base, HFA: https://godbolt.org/z/PKTz59Wev
User-provided ctor, HFA: https://godbolt.org/z/sfrTddcW6

Existing correct cases:
Empty base class, NonHFA: https://godbolt.org/z/4veY9MWP3

  • correct by accident of not allowing bases at all (see non-empty base case/fix above for counterexample)

Polymorphic: NonHFA: https://godbolt.org/z/4veY9MWP3
Trivial copy assignment, HFA: https://godbolt.org/z/Tdecj836P
Non-trivial copy assignment, NonHFA: https://godbolt.org/z/7c4bE9Whq
Non-trivial default ctor, NonHFA: https://godbolt.org/z/Tsq1EE7b7

  • correct by accident of disallowing all user-provided ctors (see user-provided non-default ctor example above for counterexample)

Trivial dtor, HFA: https://godbolt.org/z/nae999aqz
Non-trivial dtor, NonHFA: https://godbolt.org/z/69oMcshb1
Empty field, NonHFA: https://godbolt.org/z/8PTxsKKMK

  • true due to checking for the absence of padding (see comment in code)

After a bunch of testing, this fixes a bunch of cases that were
incorrect. Some of the tests verify the nuances of the existing
behavior/code checks that were already present.

This was mostly motivated by cleanup from/in D133817 which itself was
motivated by D119051.

By removing the incorrect use of isTrivialForAArch64MSVC here & adding
more nuance to the homogeneous testing we can more safely/confidently
make changes to the isTrivialFor(AArch64)MSVC to more properly align
with its usage anyway.

Diff Detail

Event Timeline

dblaikie created this revision.Sep 26 2022, 6:48 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 26 2022, 6:48 PM
dblaikie requested review of this revision.Sep 26 2022, 6:48 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 26 2022, 6:48 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
rnk added a comment.Sep 27 2022, 2:34 PM

Nice! Mostly comment copy edits.

clang/lib/CodeGen/MicrosoftCXXABI.cpp
4478–4479

These comments seem stale. Are the checks below almost equivalent to C++14 isAggregate? In any case, they associate with the logic below, which is arm-specific.

The arm check deserves some kind of comment to say that all aggregates are permitted to be HFAs for non-ARM platforms, which mostly affects vectorcall on x64/x86.

4496

typo Instnead

4499–4501

There's an open parenthetical here, maybe just make it . For example, if you have...

dblaikie updated this revision to Diff 463379.Sep 27 2022, 5:55 PM

Update comments

dblaikie marked 2 inline comments as done.Sep 27 2022, 5:58 PM
dblaikie added inline comments.
clang/lib/CodeGen/MicrosoftCXXABI.cpp
4478–4479

Not especially equivalent to C++14 aggregate, despite Microsoft's reports, I think.
For instance - the first requirement of a C++14 aggregate is that it has no user-provided ctors, but that's not a requirement for HFA: https://godbolt.org/z/Whazeha7v
& the no base classes requirement doesn't apply to HFA either - only no non-HFA base classes (& empty classes are considered non-HFA).

Updated the comment as best I could understand (I couldn't actually find the AAPCS64 rules to compare/contrast, so I'm hand waving a bit there - perhaps these ( https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#homogeneous-aggregates ) are all the rules, though they're pretty slim, and don't discuss special members at all, for instance, nor refer to any particular C++ standard for further clarification, so far as I can see)

Ping on this

rnk accepted this revision.Oct 3 2022, 3:14 PM

lgtm

This revision is now accepted and ready to land.Oct 3 2022, 3:14 PM
This revision was automatically updated to reflect the committed changes.