This is an archive of the discontinued LLVM Phabricator instance.

[AArch64] Add aarch64_vector_pcs function attribute to Clang
ClosedPublic

Authored by sdesmalen on Nov 12 2018, 5:51 AM.

Details

Summary

This is the Clang patch to complement the following LLVM patches:

https://reviews.llvm.org/D51477
https://reviews.llvm.org/D51479

More information describing the vector ABI and procedure call standard
can be found here:

https://developer.arm.com/products/software-development-tools/\

hpc/arm-compiler-for-hpc/vector-function-abi

Patch by Kerry McLaughlin.

Diff Detail

Repository
rC Clang

Event Timeline

sdesmalen created this revision.Nov 12 2018, 5:51 AM
sdesmalen added inline comments.Nov 12 2018, 5:58 AM
lib/CodeGen/CGDebugInfo.cpp
1105

I wasn't really sure whether this requires a corresponding DW_CC_LLVM_AAVPCS record in LLVM, as I couldn't find much about the DW_CC_LLVM_ encodings, specifically whether they align with some agreed encoding that is implemented by GDB/LLDB. Is this defined anywhere, or is it ignored by debuggers at the moment?

aaron.ballman added inline comments.Nov 12 2018, 4:16 PM
include/clang/Basic/Attr.td
1790

Rather than using GNU and CXX11 spellings, you should use the Clang spelling. If the attribute is not useful in C, then set allowInC to 0 instead of its default of 1.

1792

This steps on the user's namespace -- is that intended and necessary?

include/clang/Basic/AttrDocs.td
1748

64 bit -> 64-bit

sdesmalen marked an inline comment as done.Nov 13 2018, 4:13 AM
sdesmalen added inline comments.
include/clang/Basic/Attr.td
1790

Thanks for the suggestion! The attribute is valid in C as well, and is tested for both C and C++ in test/CodeGen/aarch64-vpcs.c.

1792

That was not intended and looking at the spec, the keyword is not required so I'll remove it.

sdesmalen updated this revision to Diff 173831.Nov 13 2018, 4:16 AM
  • Removed _aarch64_vector_pcs and __aarch64_vector_pcs keywords in favour of supporting only __attribute__(aarch64_vector_pcs)).

Missing sema tests that demonstrate the attribute can only appertain to functions and types, accepts no arguments, has the expected semantic behavior for typecasts to function pointers, etc.

include/clang/Basic/Attr.td
1790

Spurious whitespace around the square brackets.

include/clang/Basic/AttrDocs.td
1749–1750

If you can add a link to the vector ABI here, or to something that gives more detail about the ABI, that'd be great.

rjmccall added inline comments.Nov 15 2018, 3:09 PM
include/clang/Basic/AttrDocs.td
1749–1750

Describing this in terms of the "caller/callee saves ratio" is pretty obscure for most users. As Aaron suggestions, it's good include a link to the detailed documentation for people who want to know *exactly* what this means. For everyone else, your goal is to convince them to use your attribute in appropriate situations, so you should frame the documentation in those terms. Try this as a starting point:

Functions declared with this calling convention preserve additional floating-point and vector registers relative to the standard C convention, which makes it more efficient to call such functions within complex floating-point and vector calculations. However, this also makes it more expensive to call a standard C function within such a function. Therefore, it is recommended that this attribute be used on "leaf" functions that are likely to be used by code performing floating-point and vector calculations but that don't need to use any functions not declared with this attribute.

rnk added inline comments.Nov 16 2018, 3:44 PM
lib/CodeGen/CGDebugInfo.cpp
1105

DWARF only allows encoding 256 conventions, and we grabbed 0xC[0-F], I guess for "clang", so we probably want to be careful about adding another. Do you anticipate making debuggers able to call such functions? If not, it's probably not worth it.

rjmccall added inline comments.Nov 16 2018, 5:04 PM
lib/CodeGen/CGDebugInfo.cpp
1105

They probably should be callable.

It looks like DWARF reserves the first 64 conventions for general/language purposes and treats the rest of the range as "user" conventions. If those conventions are assumed to be universally unique, that's a really limiting schema once you started dividing it up by vendor. If I might make a suggestion, while there are certainly many calling conventions that are meant to have universal meaning (e.g. most language-specific conventions), there are also a large number that are inherently target-specific. DWARF already uses a lot of numbers that only make sense in the context of a target (like register numbers); it would make sense for DWARF to carve out a range of the encoding space (maybe 16 or 32 numbers) for target-specific CCs. This is hardly the first example; consider also all the variant ARM32 CCs or the i386 fastcall CC.

sdesmalen updated this revision to Diff 174574.Nov 19 2018, 2:34 AM
sdesmalen marked an inline comment as done.

Thanks all for the suggestions and comments! I've updated the patch with a better description of the attribute's behaviour (thanks @rjmccall for the starting point!) and added Sema tests.

sdesmalen added inline comments.
lib/CodeGen/CGDebugInfo.cpp
1105

Great feedback. I think this discussion has a wider scope than this patch and I think its probably best to keep this change as-is for now. We'll first work to add a section to the 'DWARF for the ARM 64-bit Architecture' document describing a DW_AT_calling_convention value for the AArch64 vector PCS and will create a separate patch to LLVM/Clang to implement its support. I've also asked @keith.walker.arm to raise this (encoding space) as a topic with the DWARF standardization committee.

Implementation LGTM.

include/clang/Basic/AttrDocs.td
1753

Please spell out "and".

1758

"However, using this attribute also means..."

1766

Thanks; other than those two editorial comments, this seems good.

lib/CodeGen/CGDebugInfo.cpp
1105

Thank you, I appreciate that.

Just to double check before committing, @aaron.ballman are you happy with the tests?

Just to double check before committing, @aaron.ballman are you happy with the tests?

The tests LGTM, but there are still some unresolved comments from @rjmccall that should be handled before committing.

sdesmalen updated this revision to Diff 175236.Nov 26 2018, 6:07 AM
  • resolved editorial comments.
sdesmalen marked 2 inline comments as done.Nov 26 2018, 6:08 AM
rjmccall accepted this revision.Nov 26 2018, 8:13 AM

Thanks, LGTM.

This revision is now accepted and ready to land.Nov 26 2018, 8:13 AM
This revision was automatically updated to reflect the committed changes.