"Richard Earnshaw (lists) via Gcc" <gcc@gcc.gnu.org> writes: > On 30/04/2025 18:34, Heiko Eißfeldt wrote: >>> - <li>FEAT_LRCPC2 (<code>+rcpc2</code>), enabled by default for >>> + <li>FEAT_RCPC2 (<code>+rcpc2</code>), enabled by default for >>> >>> and >>> >>> - FEAT_LRCPC3 instructions, when support for the instructions is >>> + FEAT_RCPC3 instructions, when support for the instructions is >>> >>> These are incorrect. The features really are FEAT_LRCPC2/3. >>> >>> Otherwise, I think these look generally like improvements. >>> >>> R. >> >> >> That is interesting. I did a grep on gcc trunk for 'FEAT_.*RCPC' and got this >> ./gcc/common/config/aarch64/cpuinfo.h: FEAT_RCPC, >> ./gcc/common/config/aarch64/cpuinfo.h: FEAT_RCPC2, >> ./gcc/common/config/aarch64/cpuinfo.h: FEAT_RCPC3, >> ./libgcc/config/aarch64/cpuinfo.c: setCPUFeature(FEAT_RCPC); >> ./libgcc/config/aarch64/cpuinfo.c: setCPUFeature(FEAT_RCPC2); >> ./libgcc/config/aarch64/cpuinfo.c: setCPUFeature(FEAT_RCPC3); >> >> Substring "LRCPC" I see only in conjunction with hardware capabilities but >> not features. >> >> The documentation >> (https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/AArch64-Options.html#aarch64-feature-modifiers) >> lists in chapter 3.20.1.1 "-march and -mcpu Feature Modifiers" >> >> ‘rcpc’ >> ‘rcpc2’ >> ‘rcpc3’ >> >> Finally, the substring LRCPC2 was not found in my repo at all. >> >> H. > > Yes, this is confusing. I'd expect, though, that the FEAT_... names, > especially in documents like this would be referring to the official name in > the Arm ARM. That only documents FEAT_LRCPC{,2,3}. There's no mention at > all of FEAT_RPCC. I think this is why the text above references the GCC name > (+rcpc[23]) as well.
Yeah, I just wanted to confirm that these FEAT_*s were intended to match the architectural names, so the "L"s are deliberate. It's unfortunate that the toolchain feature name differs from the architectural name, but this is due to historical reasons. The cpuinfo.* grep results above are related function multi-versioning, so are named after the toolchain feature name rather than the architectural feature name. Again, it's perhaps unfortunate that the enum uses the "FEAT_" prefix given that the names do not always correspond to the architectural feature name, but this is a shared API. Thanks, Richard
