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 4 commits
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 __pld_range(/*constant*/ unsigned int /*access_kind*/,
/*constant*/ unsigned int /*retention_policy*/,
size_t /*reuse distance*/,
signed int /*stride*/,
unsigned int /*count*/,
signed int /*length*/,
void const volatile *addr);
```

Generates a data prefetch instruction for a range of addresses starting from a
given base address. Locations within the specified address ranges are prefetched
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 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. |

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

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.

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

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

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?

@kmclaughlin-arm kmclaughlin-arm Dec 10, 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 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?

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

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

@kmclaughlin-arm kmclaughlin-arm Dec 10, 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.

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.

| Stride | [-2MiB, +2MiB) | Number of bytes to advance the block address by after `Length` |
| | | bytes have been accessed. Note: This value is ignored if Count is 1. |
| Count | [1, 65536] | Number of blocks to be accessed. |
| Length | [-2MiB, +2MiB) | Number of contiguous bytes to be accessed. |

### Instruction prefetch

``` c
Expand Down
Loading