Add FEAT_PCDPHINT Support #406
Conversation
| ### Intent to read prefetch | ||
|
|
||
| ``` c | ||
| void __ir(void const volatile *addr); |
There was a problem hiding this comment.
How about naming it __pldir since it's a variant of data prefetch?
There was a problem hiding this comment.
I like it, my only concern would be around lack of consistency with the spec around the instruction.(https://developer.arm.com/documentation/ddi0602/2025-06/Base-Instructions/PRFM--immediate---Prefetch-memory--immediate--?lang=en)
Don't know how much that matters, if we prefer the pldir name for ease of understanding in the compiler?
| To access these intrinsics, `<arm_acle.h>` should be included. | ||
|
|
||
| ``` c | ||
| void __arm_stshh_u8(void const volatile *addr, |
There was a problem hiding this comment.
The target of a store shouldn't be const qualified? And why is it volatile qualified?
And why not use the proper data type for the target pointer?
GCC atomic builtins use plain int for the memorder parameter. See https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
void __arm_stshh_u8(uint8_t *addr, uint8_t data, int memorder, int retpol);
|
|
||
| | **Memory Order** | **Value** | **Summary** | | ||
| | ------------------| --------- | -------------------------------------------------------------------------------------------------- | | ||
| | Relaxed | 0 | No constraints imposed on other reads or writes, only this operation's atomicity is guaranteed. | |
There was a problem hiding this comment.
I don't know if the ACLE has some precedent here but otherwise, I would expect us to use GCC's __ATOMIC_SEQ_CST, __ATOMIC_RELEASE and __ATOMIC_RELAXED names and values. But perhaps the actual values are not stable and thus not suitable for ACLE?
| @@ -1826,6 +1827,13 @@ The `__ARM_FEATURE_SYSREG128` macro can only be implemented in the AArch64 | |||
| execution state. Intrinsics for the use of these instructions are specified in | |||
| [Special register intrinsics](#special-register-intrinsics). | |||
|
|
|||
| ### Producer-consumer data placement hints | |||
|
|
|||
| `__ARM_FEATURE_PCDPHINT` is defined to `1` if there is hardware | |||
There was a problem hiding this comment.
Isn't __ARM_FEATURE_PCDPHINT defined (to 1) if there is compiler support? Hardware support is something else that can only be detected at runtime.
Hi all,
This is a PR to propose the addition of new intrinsics required as part of FEAT_PCDPHINT.
I'm very open to suggestions on potential improvements and certainly not overly committed to the current name.
This will need approval from LLVM as well.
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.