Add FEAT_PCDPHINT Support #406
Conversation
ricbal02
force-pushed
the
FEAT_PCDPHINT
branch
from
6ab456b to
af4a611
Compare
| `__ARM_FEATURE_PCDPHINT` is defined to `1` if the producer-consumer | ||
| data placement hints (FEAT_PCDPHINT) instructions and their associated | ||
| intrinsics are available on the target. |
There was a problem hiding this comment.
IMO as these are hint instructions the developer may want to use them on older -march targets, so the __ARM_FEATURE_PCDPHINT should only signify whether the compiler version in question supports the intrinsics, but the intrinsics themselves should be always available (presumably the hint instructions execute as NOPs on older HW?)
There was a problem hiding this comment.
Though reading a bit more, the user may not want to execute a PRFM instruction unless they know FEAT_PCDPHINT is present, so maybe it is prudent to gate these on hardware support. I don't insist on it.
ricbal02
force-pushed
the
FEAT_PCDPHINT
branch
from
af4a611 to
e067f72
Compare
ricbal02
force-pushed
the
FEAT_PCDPHINT
branch
from
e067f72 to
5977a0e
Compare
| The first argument in these intrinsics is a pointer `ptr` which is the location to store to. | ||
| The second argument `data` is the data which is to be stored. | ||
| The third argument `mem` can be one of 3 memory ordering variables from the C++11 standard supported by atomic_store: | ||
| __ATOMIC_RELAXED, __ATOMIC_SEQ_CST, and __ATOMIC_RELEASE. |
There was a problem hiding this comment.
I don't think these are in the C++11 standard with this spelling, these are GCC builtins. Also, it should probably reference C rather than C++.
| ``` c | ||
| void __arm_atomic_store_with_stshh(type *ptr, | ||
| type data, | ||
| int mem, /* Memory order */ |
There was a problem hiding this comment.
Should the type of this be memory_order like in C11?
7 participants
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.
Quality Level: ALP
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.