Add intrinsic support for the range prefetch (RPRFM) instruction #423

kmclaughlin-arm · 2025-12-01T17:01:30Z

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.

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

main/acle.md

…65536)

the range of the Count argument

main/acle.md

paulwalker-arm · 2025-12-08T17:27:13Z

main/acle.md

+              /*constant*/ unsigned int /*reuse distance*/,
+              /*constant*/ signed int   /*stride*/,
+              /*constant*/ unsigned int /*count*/,
+              /*constant*/ signed int   /*length*/,


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.

Removed /*constant*/ from the metadata arguments, as there was no specific reason requiring them to be constant.

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.

are you worried about extra spills which may cause changes to the memory and the provided values won't match the memory pattern the prefetched instruction is using?

Not specifically, just any extra work required to construct the metadata that would be invisible to the user and thus might surprise them.

paulwalker-arm · 2025-12-08T17:31:54Z

main/acle.md

+| 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.    |


Similar to the change to Count it will be more user friendly to accept the real world value and let the compiler encode it.

I've changed this to accept either 0 (for distance not known) or a value representing the number of bytes instead.

main/acle.md

paulwalker-arm · 2025-12-08T18:43:35Z

main/acle.md

 | 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:


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.

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.

Yeah I think I agree with Paul, I think we should have a __ARM_PREFETCH_RANGE macro to tell the user if this part of the ACLE is currently implemented for the compiler and is available. Then it can be used for conditional compilation?

I think we could also have a __ARM_FEATURE_RPRFM macro, to indicate if the actual feat is enabled though?

I've updated this to describe the __ARM_PREFETCH_RANGE macro.

@AlfGalf Given that the __ARM_FEATURE_RPRFM macro should be used to query whether this is implemented, I'm not sure why we would also want to add __ARM_FEATURE_RPRFM if the instruction does not require something like +rprfm?

I support @kmclaughlin-arm , the FEAT_RPRFM is OPTIONAL from Armv8.0, and not guarded by any dedicated feature flag, moreover it looks like RPRFM is a preferred disassembly for PRFM with UXTW, as guarded by this test https://github.com/llvm/llvm-project/blob/f9a3076180bfa1ebffd518971eefd30939a5ced6/llvm/test/MC/AArch64/rprfm.s#L273 , so not sure what we would achieve with having __ARM_FEATURE_RPRFM.

Ah yeah, okay, agreed best to not have __ARM_FEATURE_RPRFM

main/acle.md

- Remove const from metadata arguments - Change Reuse Distance to take a number of bytes

paulwalker-arm · 2025-12-09T16:15:35Z

main/acle.md

+              /*constant*/ unsigned int /*reuse distance*/,
+              /*constant*/ signed int   /*stride*/,
+              /*constant*/ unsigned int /*count*/,
+              /*constant*/ signed int   /*length*/,


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.

paulwalker-arm · 2025-12-09T16:18:54Z

main/acle.md

+| 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.    |


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.

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.

Does that mean the range information can be removed because the compiler can do the necessary rounding for free. Then just call out 0 and values over 512MiB are treated as unknown?

I think the range information is still accurate though, as long as it's in the description that any value outside the range will use 0 for unknown distance?

To me the range information is specifying the builtin's acceptable values for that parameter, with everything else resulting in a diagnostic. With the compiler doing implicit rounding, all values are acceptable and so there is no range. The summary can then document how values will be interpreted (e.g. All values are rounded up to the nearest power-of-two in the range low - high, with the exception of ....).

Ok, I think it makes sense to remove the range given that the rounding means there won't be any diagnostics shown for invalid values.

… value - Mark metadata arguments to __pldx_range as constant

AlfGalf

The intrinsic itself looks good to me, slight question about the macro though

AlfGalf · 2025-12-11T10:44:47Z

main/acle.md

 | 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:


Yeah I think I agree with Paul, I think we should have a __ARM_PREFETCH_RANGE macro to tell the user if this part of the ACLE is currently implemented for the compiler and is available. Then it can be used for conditional compilation?

I think we could also have a __ARM_FEATURE_RPRFM macro, to indicate if the actual feat is enabled though?

CarolineConcatto · 2025-12-11T11:02:31Z

main/acle.md

+
+| **Metadata**   | **Range**           | **Summary**                                                          |
+| -------------- | ------------------- | -------------------------------------------------------------------- |
+| Reuse Distance |                     | Maximum number of bytes to be accessed before executing the next     |


Should we also add the Range here for Reuse Distance?

Hi @CarolineConcatto, the reason for removing the Reuse Distance range was discussed here: #423 (comment)

- Add description of the __ARM_PREFETCH_RANGE macro

paulwalker-arm

I'm mostly happy, with one last query.

paulwalker-arm · 2025-12-12T12:18:52Z

main/acle.md

+                    /*constant*/ size_t       /*reuse distance*/,
+                    /*constant*/ signed int   /*stride*/,
+                    /*constant*/ unsigned int /*count*/,
+                    /*constant*/ signed int   /*length*/,


Not a strongly held view, but after reading the description of __pld_range I do feel its "parameters" have a more natural order (i.e. length, count, stride, reuse distance). What do you think to using the same order for __pldx_range?

I think it would be better if the order is consistent for both of the intrinsics, and it makes sense to keep the ordering from bits 0-63 used by __pld_range.

…istance

AlfieRichardsArm

LGTM

Add intrinsic support for the range prefetch (RPRFM) instruction.

8ab80d6

kmclaughlin-arm requested a review from CarolineConcatto December 1, 2025 17:01

kmclaughlin-arm mentioned this pull request Dec 3, 2025

[AArch64] Add support for range prefetch intrinsic llvm/llvm-project#170490

Open

mgabka reviewed Dec 4, 2025

View reviewed changes

main/acle.md Outdated Show resolved Hide resolved

kmclaughlin-arm added 2 commits December 8, 2025 11:50

- Define Count as the number of data blocks to be accessed (i.e. 1 - …

d9b772a

…65536)

- Fix comment "This value is ignored if Count is 0" after changing

a3a51f8

the range of the Count argument

paulwalker-arm reviewed Dec 8, 2025

View reviewed changes

- Rename __rpld to __pld_range

4616a23

- Remove const from metadata arguments - Change Reuse Distance to take a number of bytes

paulwalker-arm reviewed Dec 9, 2025

View reviewed changes

kmclaughlin-arm added 2 commits December 9, 2025 17:38

- Add a second builtin allowing the metadata to be passed as a single…

e53af76

… value - Mark metadata arguments to __pldx_range as constant

- Remove Range information from Reuse Distance description

3513fc7

AlfGalf reviewed Dec 11, 2025

View reviewed changes

CarolineConcatto reviewed Dec 11, 2025

View reviewed changes

- Remove reference to __ARM_FEATURE_RPRFM

cb32719

- Add description of the __ARM_PREFETCH_RANGE macro

paulwalker-arm reviewed Dec 12, 2025

View reviewed changes

- Reorder arguments of _pldx_range to length, count, stride & reuse d…

25ea5c8

…istance

AlfieRichardsArm approved these changes Dec 12, 2025

View reviewed changes

paulwalker-arm approved these changes Dec 12, 2025

View reviewed changes

Add intrinsic support for the range prefetch (RPRFM) instruction #423

Are you sure you want to change the base?

Add intrinsic support for the range prefetch (RPRFM) instruction #423

Uh oh!

Conversation

kmclaughlin-arm commented Dec 1, 2025

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlfGalf left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

paulwalker-arm left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlfieRichardsArm left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants