Minor modification to FMV rules for scope and signatures #363

AlfieRichardsArm · 2024-11-21T16:54:49Z

Hi all,

While attempting to implement FMV in the GCC front-end some questions were raised that I think are worth clarifying here.

This PR changes the rules to use the default function to determine the signature and scope of the versioned function set.

This clears up some cases such as:

int fn (int c = 1);
int __attribute__((target_version("sve"))) fn (int c = 2);

int bar() { return fn(); }

Where there are conflicting signatures and which default should be used is not clear at the moment.

int fn (int c[]);
int __attribute__((target_version("default"))) fn (int c[1]) {
}
int __attribute__((target_version("sve"))) fn (int c[2]) {
}

Where if this should be considered a conflicting signature is not clear.

int __attribute__((target_version("default"))) fn (int x) {
    return 1;
}

void bar () {
    int __attribute__((target_version("sve2"))) fn (int);
    fn(1);
}

Where the scope of multi-versioned functions differs.

And

// TU 1
#import TU2

int fn (int c = 1);

int bar() { return fn(); }

// TU 2

int __attribute__((target_version("sve"))) fn (int c = 2);
int __attribute__((target_version("sve2"))) fn (int c = 2);

int bar() { return fn(); }

Where it is possible calls in different TU's could use different default argument values.

name: Pull request
about: Technical issues, document format problems, bugs in scripts or feature proposal.

Thank you for submitting a pull request!

If this PR is about a bugfix:

Please use the bugfix label and make sure to go through the checklist below.

If this PR is about a proposal:

We are looking forward to evaluate your proposal, and if possible to
make it part of the Arm C Language Extension (ACLE) specifications.

We would like to encourage you reading through the contribution
guidelines, in particular the section on submitting
a proposal.

Please use the proposal label.

As for any pull request, please make sure to go through the below
checklist.

Checklist: (mark with X those which apply)

If an issue reporting the bug exists, I have mentioned it in the
PR (do not bother creating the issue if all you want to do is
fixing the bug yourself).
I have added/updated the SPDX-FileCopyrightText lines on top
of any file I have edited. Format is SPDX-FileCopyrightText: Copyright {year} {entity or name} <{contact informations}>
(Please update existing copyright lines if applicable. You can
specify year ranges with hyphen , as in 2017-2019, and use
commas to separate gaps, as in 2018-2020, 2022).
I have updated the Copyright section of the sources of the
specification I have edited (this will show up in the text
rendered in the PDF and other output format supported). The
format is the same described in the previous item.
I have run the CI scripts (if applicable, as they might be
tricky to set up on non-*nix machines). The sequence can be
found in the contribution
guidelines. Don't
worry if you cannot run these scripts on your machine, your
patch will be automatically checked in the Actions of the pull
request.
I have added an item that describes the changes I have
introduced in this PR in the section Changes for next
release of the section Change Control/Document history
of the document. Create Changes for next release if it does
not exist. Notice that changes that are not modifying the
content and rendering of the specifications (both HTML and PDF)
do not need to be listed.
When modifying content and/or its rendering, I have checked the
correctness of the result in the PDF output (please refer to the
instructions on how to build the PDFs
locally).
The variable draftversion is set to true in the YAML header
of the sources of the specifications I have modified.
Please DO NOT add my GitHub profile to the list of contributors
in the README page of the project.

main/acle.md

AlfieRichardsArm · 2024-12-12T13:31:09Z

I have updated this PR with (hopefully) clearer wording more inline with @labrinea 's suggestions.

main/acle.md

AlfieRichardsArm · 2024-12-17T12:28:34Z

I have changed the rule for whats allowed signature wise after a suggestion by @rsandifo-arm which makes it more precise in terms of function types and added some examples.

Specifically, the rule change specifies compatibility in terms of if the types are compatible, and the example shows this in terms of function pointers.
The argument there being that behind the scenes FMV is the load time initialization of a function pointer, so it makes sense to consider compatibility in terms of function pointer compatibility.

main/acle.md

vhscampos · 2024-12-19T10:02:28Z

If no objections are raised, let's merge this on the 23 December.

main/acle.md

AlfieRichardsArm · 2025-01-03T09:39:40Z

@labrinea Thank you for the feedback, I addressed them and in doing so moved some stuff around slightly so I hope it makes more sense now.

labrinea · 2025-01-03T11:52:42Z

May we move the sentence https://github.com/ARM-software/acle/blob/main/main/acle.md?plain=1#L2695 here https://github.com/ARM-software/acle/blob/main/main/acle.md?plain=1#L2677 and rephase it as "Functions are allowed to have the same name when annotated with these attributes." Then in https://github.com/ARM-software/acle/blob/main/main/acle.md?plain=1#L2695 we could say "when applied to a function it becomes one of the versions. Multiple function versions may exist in the same or in different translation units."

Now regarding the order of bullet points I think it could be improved to help the reader. For example the second bullet point refers to the default version a bit suddenly. The third bullet point refers to the table of features which mentions 'default' for the first time in this document.

Also some of thebullet points refer to FMV semantics whereas others specifically refer to the FMV attributes. Perhaps it's worth separating those.

This can be done in a separate commit.

main/acle.md

AlfieRichardsArm · 2025-01-03T16:19:35Z

I agree the bullets can be made clearer. I will look into making another PR for that work shortly.

I addressed your feedback and while reading through made a few other touches to parts hopefully within scope for this change to make it a little clearer.

main/acle.md

Changes the Function multiversioning rules for `target_version` such that the signature and scope for a set of FMV functions is that of the default version. This patch also adds some examples documenting the rules and behavior.

philgee-oss · 2025-02-18T13:26:42Z

main/acle.md

 * These attributes can be mixed with each other.
+* `name` is the dependent features from the tables below.


Don't use below or above, because they can be ambiguous. Best to cross-reference to the section containing the tables (Mapping?)

philgee-oss · 2025-02-18T13:27:45Z

main/acle.md

 * The `default` version means the version of the function that would
  be generated without these attributes.
-* `name` is the dependent features from the tables below.
 * The dependent features could be joined by the `+` sign.
 * None of these attributes will enable the corresponding ACLE feature(s)


attributes enable

philgee-oss · 2025-02-18T13:28:07Z

main/acle.md

@@ -2687,21 +2691,46 @@ The following attributes trigger the multi version code generation:
 * If only the `default` version exist it should be linked directly.
 * FMV may be disabled in compile time by a compiler flag. In this


philgee-oss · 2025-02-18T13:28:22Z

main/acle.md

@@ -2687,21 +2691,46 @@ The following attributes trigger the multi version code generation:
 * If only the `default` version exist it should be linked directly.
 * FMV may be disabled in compile time by a compiler flag. In this
  case the `default` version shall be used.


philgee-oss · 2025-02-18T13:29:49Z

main/acle.md

-* All the function versions must be declared at the translation
-  unit in which the definition of the default version resides.
+
+For example, the below is valid and 2 is used as the default


The following example is valid

philgee-oss · 2025-02-18T13:30:27Z

main/acle.md

+int g() { return f(); }
+```
+
+Additionally, the below is not valid as the two statements declare


Additionally, the following example is not valid because

AlfieRichardsArm · 2025-02-18T13:35:00Z

@philgee-oss Hi, thanks for the feedback, however this has been merged as of 6th Jan.
I can open a new PR and address these if you think its worth it?

vhscampos · 2025-02-18T13:38:34Z

@philgee-oss Hi, thanks for the feedback, however this has been merged as of 6th Jan. I can open a new PR and address these if you think its worth it?

Hi @AlfieRichardsArm , don't worry, I will fix all the issues raised by Phil

labrinea reviewed Nov 25, 2024

View reviewed changes

main/acle.md Outdated Show resolved Hide resolved

main/acle.md Show resolved Hide resolved

main/acle.md Outdated Show resolved Hide resolved

main/acle.md Outdated Show resolved Hide resolved

AlfieRichardsArm requested a review from labrinea November 26, 2024 13:41

AlfieRichardsArm force-pushed the main branch from 9f40b3a to a0a77a9 Compare December 12, 2024 13:30

AlfieRichardsArm changed the title ~~Add clarification and restrictions for FMV~~ Minor modification to FMV rules for scope and signatures. Dec 13, 2024

AlfieRichardsArm changed the title ~~Minor modification to FMV rules for scope and signatures.~~ Minor modification to FMV rules for scope and signatures Dec 13, 2024

labrinea approved these changes Dec 16, 2024

View reviewed changes

main/acle.md Show resolved Hide resolved

main/acle.md Outdated Show resolved Hide resolved

AlfieRichardsArm force-pushed the main branch from a0a77a9 to 5752052 Compare December 17, 2024 12:24

labrinea reviewed Dec 17, 2024

View reviewed changes

main/acle.md Outdated Show resolved Hide resolved

main/acle.md Outdated Show resolved Hide resolved

main/acle.md Outdated Show resolved Hide resolved

main/acle.md Outdated Show resolved Hide resolved

AlfieRichardsArm force-pushed the main branch from 5752052 to a34b492 Compare December 18, 2024 11:46

labrinea approved these changes Dec 18, 2024

View reviewed changes

main/acle.md Outdated Show resolved Hide resolved

AlfieRichardsArm force-pushed the main branch from a34b492 to ad06c49 Compare December 18, 2024 12:13

rsandifo-arm reviewed Dec 19, 2024

View reviewed changes

main/acle.md Show resolved Hide resolved

jroelofs approved these changes Dec 19, 2024

View reviewed changes

AlfieRichardsArm force-pushed the main branch from ad06c49 to 03048e4 Compare December 20, 2024 18:03

labrinea reviewed Dec 20, 2024

View reviewed changes

main/acle.md Outdated Show resolved Hide resolved

AlfieRichardsArm force-pushed the main branch from 03048e4 to 513982a Compare December 20, 2024 23:09

AlfieRichardsArm force-pushed the main branch from 513982a to c1e274f Compare January 2, 2025 08:55

labrinea reviewed Jan 2, 2025

View reviewed changes

main/acle.md Outdated Show resolved Hide resolved

main/acle.md Outdated Show resolved Hide resolved

AlfieRichardsArm force-pushed the main branch from c1e274f to 848be84 Compare January 3, 2025 09:38

labrinea reviewed Jan 3, 2025

View reviewed changes

main/acle.md Outdated Show resolved Hide resolved

AlfieRichardsArm force-pushed the main branch from 848be84 to d614cd2 Compare January 3, 2025 16:17

labrinea reviewed Jan 3, 2025

View reviewed changes

main/acle.md Outdated Show resolved Hide resolved

AlfieRichardsArm force-pushed the main branch from d614cd2 to 9d315bb Compare January 6, 2025 09:11

labrinea approved these changes Jan 6, 2025

View reviewed changes

vhscampos merged commit afd6b56 into ARM-software:main Jan 6, 2025
4 checks passed

philgee-oss reviewed Feb 18, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Minor modification to FMV rules for scope and signatures #363

Minor modification to FMV rules for scope and signatures #363

AlfieRichardsArm commented Nov 21, 2024 •

edited

Loading

AlfieRichardsArm commented Dec 12, 2024 •

edited

Loading

AlfieRichardsArm commented Dec 17, 2024

vhscampos commented Dec 19, 2024

AlfieRichardsArm commented Jan 3, 2025

labrinea commented Jan 3, 2025

AlfieRichardsArm commented Jan 3, 2025

philgee-oss Feb 18, 2025

philgee-oss Feb 18, 2025

philgee-oss Feb 18, 2025

philgee-oss Feb 18, 2025

philgee-oss Feb 18, 2025

philgee-oss Feb 18, 2025

AlfieRichardsArm commented Feb 18, 2025

vhscampos commented Feb 18, 2025

		* These attributes can be mixed with each other.
		* `name` is the dependent features from the tables below.

		@@ -2687,21 +2691,46 @@ The following attributes trigger the multi version code generation:
		* If only the `default` version exist it should be linked directly.
		* FMV may be disabled in compile time by a compiler flag. In this

Minor modification to FMV rules for scope and signatures #363

Minor modification to FMV rules for scope and signatures #363

Conversation

AlfieRichardsArm commented Nov 21, 2024 • edited Loading

AlfieRichardsArm commented Dec 12, 2024 • edited Loading

AlfieRichardsArm commented Dec 17, 2024

vhscampos commented Dec 19, 2024

AlfieRichardsArm commented Jan 3, 2025

labrinea commented Jan 3, 2025

AlfieRichardsArm commented Jan 3, 2025

philgee-oss Feb 18, 2025

Choose a reason for hiding this comment

philgee-oss Feb 18, 2025

Choose a reason for hiding this comment

philgee-oss Feb 18, 2025

Choose a reason for hiding this comment

philgee-oss Feb 18, 2025

Choose a reason for hiding this comment

philgee-oss Feb 18, 2025

Choose a reason for hiding this comment

philgee-oss Feb 18, 2025

Choose a reason for hiding this comment

AlfieRichardsArm commented Feb 18, 2025

vhscampos commented Feb 18, 2025

AlfieRichardsArm commented Nov 21, 2024 •

edited

Loading

AlfieRichardsArm commented Dec 12, 2024 •

edited

Loading