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.

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

[FMV] Add Priority syntax for version selection order #85

Open
wants to merge 15 commits into
base: main
Choose a base branch
from
63 changes: 39 additions & 24 deletions riscv-c-api.md
Original file line number Diff line number Diff line change
Expand Up @@ -299,8 +299,21 @@ Each `TARGET-CLONES-ATTR-STRING` defines a distinguished version of the function
The syntax of `<TARGET-CLONES-ATTR-STRING>` describes below:

```
TARGET-CLONES-ATTR-STRING := 'arch=' EXTENSIONS
Copy link

Choose a reason for hiding this comment

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

It looks like you may have re-odered the BPF. Please undo this as it makes the diff really hard to read.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Does it look better now?

| 'default'
TARGET-CLONES-ATTR-STRING := 'default'
| ATTR-STRINGS

ATTR-STRINGS := ATTR-STRING
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this be

ATTR-STRINGS := ATTR-STRING ';' ATTR-STRINGS
                | ATTR-STRING

that more closely matches how EXTENSIONS is defined.

| ';' ATTR-STRINGS

ATTR-STRING := ARCH-ATTR ';' PRIORITY-ATTR
| PRIORITY-ATTR ';' ARCH-ATTR
| ARCH-ATTR

ARCH-ATTR := 'arch=' EXTENSIONS

PRIORITY-ATTR := 'priority=' DIGITS

DIGITS := [0-9]+

EXTENSIONS := <EXTENSION> ',' <EXTENSIONS>
| <EXTENSION>
Expand All @@ -319,7 +332,7 @@ EXTENSION-NAME := Naming rule is defined in RISC-V ISA manual
For example, the following `foo` function will have three versions but share the same function signature.

```c
__attribute__((target_clones("arch=+v", "default", "arch=+zbb")))
__attribute__((target_clones("arch=+v;priority=2", "default", "arch=+zbb;priority=1")))
int foo(int a)
{
return a + 5;
Expand All @@ -331,6 +344,8 @@ int bar() {
}
```

The `priority` accepts a digit as the version priority during [Version Selection](#version-selection). If `priority` isn't specified, then the priority of version defaults to zero.
Copy link

Choose a reason for hiding this comment

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

Now that we accept -1, we have to state ordering. Does "-1" compare less than "1" (i.e. signed ordering), or does it mean "maximum priority" (i.e. unsigned ordering)? I think we probably want unsigned here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I assume the signed ordering here, and I also use it in the LLVM implementation. It's just more intuitive to me, but I can change to unsigned ordering if necessary.

Copy link
Contributor

@topperc topperc Sep 25, 2024

Choose a reason for hiding this comment

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

Why do we need to allow negative numbers at all?

Copy link
Contributor

Choose a reason for hiding this comment

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

@preames do you see any reason to support negative numbers here? The number of target_clones/target_version attributes should be small enough that setting even a smallish number like 1000 should be high enough to be maximum priority.

Copy link

Choose a reason for hiding this comment

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

Nope, restricting it to positive only would be fine. I just want to make sure the interpretation is unambiguous.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removing negative numbers from the priority appears to be a clearer solution to avoid ambiguity. I will update this in the pull request.


It makes the compiler trigger the [function multi-version](#function-multi-version) when there exist more than one version for the same function signature.

### `__attribute__((target_version("<TARGET-VERSION-ATTR-STRING>")))`
Expand All @@ -339,36 +354,18 @@ The `target_version` attribute is used to create one version of a function. Func

Each `TARGET-VERSION-ATTR-STRING` defines a distinguished version of the function. If there is more than one version for the same function, it must have `default` one that indicating the translation unit scope build attributes.

The syntax of `<TARGET-VERSION-ATTR-STRING>` describes below:

```
TARGET-VERSION-ATTR-STRING := 'arch=' EXTENSIONS
| 'default'

EXTENSIONS := <EXTENSION> ',' <EXTENSIONS>
| <EXTENSION>

EXTENSION := <OP> <EXTENSION-NAME> <VERSION>

OP := '+'

VERSION := [0-9]+ 'p' [0-9]+
| [1-9][0-9]*
|

EXTENSION-NAME := Naming rule is defined in RISC-V ISA manual
```
The syntax of `<TARGET-VERSION-ATTR-STRING>` is the same as described above for `<TARGET-CLONES-ATTR-STRING>`.

For example, the following foo function has three versions.

```c
__attribute__((target_version("arch=+v")))
__attribute__((target_version("arch=+v;priority=1")))
int foo(int a)
{
return a + 5;
}

__attribute__((target_version("arch=+zbb")))
__attribute__((target_version("arch=+zbb;priority=2")))
int foo(int a)
{
return a + 5;
Expand All @@ -386,6 +383,10 @@ int bar() {
}
```

The `priority` accepts a digit as the version priority during [Version Selection](#version-selection). If `priority` isn't specified, then the priority of version defaults to zero.

The `default` version does not accept the priority.

It makes the compiler trigger the [function multi-version](#function-multi-version) when there exist more than one version for the same function signature.

### riscv_vector_cc
Expand Down Expand Up @@ -708,3 +709,17 @@ statements, including both RISC-V specific and common operand modifiers.
Function multi-versioning(FMV) provides an approach to selecting the appropriate function according to the runtime environment. The final binary may contain all versions of the function, with the compiler generating all supported versions and the runtime selecting the appropriate one.

This feature is triggered by `target_version/target_clones` function attribute.

### Version Selection

The process of selecting the appropriate function version during function multi-versioning follows these guidelines:

1. The implementation of the selection algorithm is implementation-specific.
2. Once a version is selected, it remains in use for the entire duration of the process.
3. Only versions whose required features are all available in the runtime environment are eligible for selection.

The version selection process applies the following rules in order:

1. Among the eligible versions, select the one with the highest priority.
2. If multiple versions have equal priority, select one based on an implementation-defined heuristic.
3. If no other suitable versions are found, fall back to the "default" version.