Skip to content

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

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

Merged
vhscampos merged 11 commits into from
Jan 12, 2026
Merged

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

Changes from 1 commit
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
8ab80d6
Add intrinsic support for the range prefetch (RPRFM) instruction.
kmclaughlin-arm Nov 20, 2025
d9b772a
- Define Count as the number of data blocks to be accessed (i.e. 1 - …
kmclaughlin-arm Dec 8, 2025
a3a51f8
- Fix comment "This value is ignored if Count is 0" after changing
kmclaughlin-arm Dec 8, 2025
4616a23
- Rename __rpld to __pld_range
kmclaughlin-arm Dec 9, 2025
e53af76
- Add a second builtin allowing the metadata to be passed as a single…
kmclaughlin-arm Dec 9, 2025
3513fc7
- Remove Range information from Reuse Distance description
kmclaughlin-arm Dec 10, 2025
cb32719
- Remove reference to __ARM_FEATURE_RPRFM
kmclaughlin-arm Dec 11, 2025
25ea5c8
- Reorder arguments of _pldx_range to length, count, stride & reuse d…
kmclaughlin-arm Dec 12, 2025
f6f04b5
- Change metadata from unsigned long to uint64_t
kmclaughlin-arm Jan 6, 2026
11a6ba8
- Updated note added under 'changes for next release'
kmclaughlin-arm Jan 8, 2026
923d671
Merge branch 'main' into range-prefetch
vhscampos Jan 12, 2026
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
46 changes: 46 additions & 0 deletions main/acle.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -471,6 +471,7 @@ Armv8.4-A [[ARMARMv84]](#ARMARMv84). Support is added for the Dot Product intrin

* Added support for modal 8-bit floating point matrix multiply-accumulate widening intrinsics.
* Added support for 16-bit floating point matrix multiply-accumulate widening intrinsics.
* Added support for range prefetch intrinsic when `__ARM_FEATURE_RPRFM` is defined.

### References

Expand Down Expand Up @@ -3613,6 +3614,51 @@ values.
| 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:

@paulwalker-arm paulwalker-arm Dec 8, 2025

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

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.

@kmclaughlin-arm kmclaughlin-arm Dec 9, 2025

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

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.

@AlfGalf AlfGalf Dec 11, 2025

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

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?

@kmclaughlin-arm kmclaughlin-arm Dec 11, 2025

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

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?

@mgabka mgabka Dec 12, 2025

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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.

@AlfieRichardsArm AlfieRichardsArm Dec 12, 2025

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Ah yeah, okay, agreed best to not have __ARM_FEATURE_RPRFM


``` c
void __rpld(/*constant*/ unsigned int /*access_kind*/,
Comment thread
kmclaughlin-arm marked this conversation as resolved.
Outdated
/*constant*/ unsigned int /*retention_policy*/,
/*constant*/ unsigned int /*reuse distance*/,
/*constant*/ signed int /*stride*/,
/*constant*/ unsigned int /*count*/,
/*constant*/ signed int /*length*/,

@paulwalker-arm paulwalker-arm Dec 8, 2025

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

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.

@kmclaughlin-arm kmclaughlin-arm Dec 9, 2025

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

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

@paulwalker-arm paulwalker-arm Dec 9, 2025

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

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.

@mgabka mgabka Dec 10, 2025

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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?

@paulwalker-arm paulwalker-arm Dec 10, 2025

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

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

void const volatile *addr);
```

Generates a data prefetch instruction from a range of addresses starting from a
given base address. Locations within the specified address ranges are prefetched
Comment thread
kmclaughlin-arm marked this conversation as resolved.
Outdated
into one or more caches. This intrinsic allows the specification of the
expected access kind (read or write), the data retention policy (temporal or
streaming) and the reuse distance, stride, count and length metadata values.

The access kind and data retention policy arguments can only be one of the
following values.

| **Access Kind** | **Value** | **Summary** |
| --------------- | --------- | ---------------------------------------- |
| PLD | 0 | Fetch the addressed location for reading |
| PST | 1 | Fetch the addressed location for writing |

| **Retention Policy** | **Value** | **Summary** |
| -------------------- | --------- | -------------------------------------------------------------------------- |
| 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 table below describes the ranges of the reuse distance, stride, count and length arguments.

| **Metadata** | **Range** | **Summary** |
| -------------- | ----------------- | -------------------------------------------------------------------- |
| 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. |

@paulwalker-arm paulwalker-arm Dec 8, 2025

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

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

@kmclaughlin-arm kmclaughlin-arm Dec 9, 2025

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

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

| Stride | -2MiB to +2MiB-1B | Number of bytes to advance the block address by after `Length` |
Comment thread
kmclaughlin-arm marked this conversation as resolved.
Outdated
| | | bytes have been accessed. Note: This value is ignored if Count is 0. |
| Count | 0 to 65535 | Number of blocks to be accessed, minus 1. |
Comment thread
kmclaughlin-arm marked this conversation as resolved.
Outdated
| Length | -2MiB to +2MiB-1B | Number of contiguous bytes to be accessed. |
Comment thread
kmclaughlin-arm marked this conversation as resolved.
Outdated

### Instruction prefetch

``` c
Expand Down
Loading