Add intrinsic support for the range prefetch (RPRFM) instruction #423
Conversation
This patch adds support in Clang for the RPRFM instruction, which is
available when FEAT_RPRFM is defined:
void __rpld(int64_t access_kind, uint64_t retention_policy
uint64_t reuse distance, int64_t stride,
uint64_t count, int64_t length, void const *addr);
If FEAT_RPRFM is not available, this instruction is a NOP.
This implements the following ACLE proposal:
ARM-software/acle#423
the range of the Count argument
main/acle.md
Outdated
| /*constant*/ unsigned int /*reuse distance*/, | ||
| /*constant*/ signed int /*stride*/, | ||
| /*constant*/ unsigned int /*count*/, | ||
| /*constant*/ signed int /*length*/, |
There was a problem hiding this comment.
These parameters are not linked to the opcode and thus don't need to be constant?
I don't know the expected usage so perhaps making these variable is asking for trouble? In which case I think it's worth adding a variant where the metadata is an opaque value so at least there's a way to generate the prefetch for the non-constant use case without needing to use inline asm.
There was a problem hiding this comment.
Removed /*constant*/ from the metadata arguments, as there was no specific reason requiring them to be constant.
There was a problem hiding this comment.
I doubt it'll be this easy. By allowing variable arguments the compiler will then need to sanitise their values, which I think will be non-trivial and potentially result in adding a prefetch causing performance regressions due to the unexpected overhead. This is why I suggested a separate builtin where the metadata is a single opaque value, because then the user can see the overhead, because they've had to compute it manually.
main/acle.md
Outdated
| | Reuse Distance | 0 to 15 | Maximum number of bytes to be accessed before executing the | | ||
| | | | next RPRFM instruction that specifies the same range. Values | | ||
| | | | from 1 to 15 represent decreasing powers of two in the range | | ||
| | | | 512MiB to 32KiB. A value of 0 indicates distance not known. | | ||
| | | | Note: This value is ignored if a streaming prefetch is specified. | |
There was a problem hiding this comment.
Similar to the change to Count it will be more user friendly to accept the real world value and let the compiler encode it.
There was a problem hiding this comment.
I've changed this to accept either 0 (for distance not known) or a value representing the number of bytes instead.
| | KEEP | 0 | Temporal fetch of the addressed location (that is, allocate in cache normally) | | ||
| | STRM | 1 | Streaming fetch of the addressed location (that is, memory used only once) | | ||
|
|
||
| The following intrinsic is also available when `__ARM_FEATURE_RPRFM` is defined: |
There was a problem hiding this comment.
Is the expectation for the builtin to fail compilation when this feature is not present? or be treated as a NOP? The existing _pld documentation suggests the latter.
I guess it comes down to whether the builtin provides useful information that can be used even if RPRFM is not available (e.g. by emitting other prefetch instructions, or non-temporal accesses).
The reason I mention this is because if there's only a weak link to the underlying instruction then we'll not want to use a feature macro, but instead something that just says the builtin is available, like __ARM_PREFIX_RANGE.
There was a problem hiding this comment.
I think the existing documentation above the _pld builtin applies here too, in that the range builtin should not fail when the feature is not present and is treated as a nop.
- Remove const from metadata arguments - Change Reuse Distance to take a number of bytes
main/acle.md
Outdated
| /*constant*/ unsigned int /*reuse distance*/, | ||
| /*constant*/ signed int /*stride*/, | ||
| /*constant*/ unsigned int /*count*/, | ||
| /*constant*/ signed int /*length*/, |
There was a problem hiding this comment.
I doubt it'll be this easy. By allowing variable arguments the compiler will then need to sanitise their values, which I think will be non-trivial and potentially result in adding a prefetch causing performance regressions due to the unexpected overhead. This is why I suggested a separate builtin where the metadata is a single opaque value, because then the user can see the overhead, because they've had to compute it manually.
| | Reuse Distance | 0 or [2**15, 2**29] | Maximum number of bytes to be accessed before executing the | | ||
| | | | next RPRFM instruction that specifies the same range. Values | | ||
| | | | are powers of two representing the number of bytes in the range | | ||
| | | | 32KiB to 512MiB. A value of 0 indicates distance not known. | | ||
| | | | Note: This value is ignored if a streaming prefetch is specified. | |
There was a problem hiding this comment.
Do you know how accurate Reuse Distance needs to be? It says "Maximum number of bytes" so I take that to mean you can access less. I ask because perhaps this can be freeform, with the compiler selecting the lowest compatible value, or 0 for values above the maximum allowed.
There was a problem hiding this comment.
I haven't found anything to say that ReuseDistance needs to be accurate, so my understanding is also that it could access less than the number of bytes requested.
… value - Mark metadata arguments to __pldx_range as constant
3 participants
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
Xthose which apply)PR (do not bother creating the issue if all you want to do is
fixing the bug yourself).
SPDX-FileCopyrightTextlines on topof 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 usecommas to separate gaps, as in
2018-2020, 2022).Copyrightsection of the sources of thespecification 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.
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.
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.
correctness of the result in the PDF output (please refer to the
instructions on how to build the PDFs
locally).
draftversionis set totruein the YAML headerof the sources of the specifications I have modified.
in the README page of the project.