Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Include SME attributes in the name mangling of types #290

Closed
wants to merge 5 commits into from
Closed

Include SME attributes in the name mangling of types #290

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
0d1959b
Include SME attributes in the name mangling of types
kmclaughlin-arm Oct 11, 2024
44e8a55
Fix errors from check-rst-syntax
kmclaughlin-arm Oct 11, 2024
55f3e6d
- Remove suffix representing SME attributes and instead describe mang…
kmclaughlin-arm Oct 15, 2024
d71f379
- Removed separate values for preserves ZA & ZT0 as these are also ZA…
kmclaughlin-arm Oct 16, 2024
0495b41
- Corrections to example name manglings
kmclaughlin-arm Oct 17, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
60 changes: 60 additions & 0 deletions aapcs64/aapcs64.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -256,6 +256,7 @@ changes to the content of the document for that release.
| | September 2024 | - Add soft-float PCS variant. |
| | | - Add the __arm_get_current_vg SME support routine. |
| | | - Clarify use of `it` when preserving z and p registers. |
| | | - Update C++ mangling to include SME attributes in type names |
+------------+--------------------+------------------------------------------------------------------+

References
Expand Down Expand Up @@ -3111,6 +3112,65 @@ instead.
The SVE tuple types are mangled using their ``arm_sve.h`` names
(``svBASExN_t``).

Function types which have SME streaming, ZA interface or ZT0 interface attributes must include these attributes in the name mangling of the type.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like @efriedma-quic says, the intention was to include this mangling if and only if the mangling would normally include the return type of the function. We should probably say that explicitly.


SME attributes are mangled in the same way as a template:

template<typename, unsigned, unsigned, unsigned> __SME_ATTRS;

with the arguments:

__SME_ATTRS<normal_function_type, streaming_mode, za_state, zt0_state>;

where:

* normal_function_type is the function type without any SME attributes.

* streaming_mode is an integer representing the streaming-mode of the function:

+------------------------+--------------------------+
| Interface Type | Value |
+========================+==========================+
| Normal (default) | 0 |
+------------------------+--------------------------+
| Streaming Mode | 1 |
+------------------------+--------------------------+
| Streaming-Compatible | 2 |
+------------------------+--------------------------+

* za_state is an integer representing the ZA state of the function:

+------------------------+--------------------------+
| Interface Type | Value |
+========================+==========================+
| No ZA State (default) | 0 |
+------------------------+--------------------------+
| Shared ZA | 1 |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason for mangling the ZA information is to deal with the fact that the sharing attributes create distinct function types for overloading purposes. I think this means that we need to represent all five possibilities:

  • normal
  • __arm_in("za")
  • __arm_inout("za")
  • __arm_out("za")
  • __arm_preserves("za")

Similarly for zt0.

Since that classification is only described in the ACLE, we should probably describe the mangling there too. Sorry for only realising that now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @rsandifo-arm, I've updated this to represent each of the shared ZA/ZT0 attributes separately and moved these changes to the ACLE (ARM-software/acle#358).

+------------------------+--------------------------+

* zt0_state is an integer representing the ZT0 state of the function:

+------------------------+--------------------------+
| Interface Type | Value |
+========================+==========================+
| No ZT0 State (default) | 0 |
+------------------------+--------------------------+
| Shared ZT0 | 1 |
+------------------------+--------------------------+

For example:

.. code-block:: c++

// Mangled as fP11__SME_ATTRSIFu10__SVInt8_tELj1ELj0ELj0EE
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there's a missing v after the function's return type:

Empty parameter lists, whether declared as () or conventionally as (void), are encoded with a void parameter specifier (v). Therefore function types always encode at least one parameter type, and function manglings can always be distinguished from data manglings by the presence of the type. Member functions do not encode the types of implicit parameters, either this or the VTT parameter.

Also, we should probably include the leading _Z1. I think that gives: _Z1fP11__SME_ATTRSIFu10__SVInt8_tvELj1ELj0ELj0EE (verified with c++filt and compiling a dummy workalike).

void f(svint8_t (*fn)() __arm_streaming) { fn(); }

// Mangled as fP11__SME_ATTRSIFu10__SVInt8_tELj2ELj1ELj0EE
void f(svint8_t (*fn)() __arm_streaming_compatible __arm_inout("za")) { fn(); }

// Mangled as fP11__SME_ATTRSIFu10__SVInt8_tELj0ELj0ELj1EE
void f(svint8_t (*fn)() __arm_in("zt0")) { fn(); }

.. raw:: pdf

PageBreak
Expand Down