[PATCH] docs: Add documentation for TARGET_HAS_FMV_TARGET_ATTRIBUTE macro

2025-09-08 Thread alfie.richards
From: Alfie Richards Hi all, I sent this previously after Richard S noted that this hook was lacking comments but it seemingly got lost in the period where I broke my send-mail config. This describes the hook as it will be after my FMV patch series lands, so wont commit until thats in. Reg tes

[PATCH v10 10/13] aarch64: Remove FMV beta warning.

2025-08-28 Thread alfie.richards
From: Alfie Richards This patch removes the warning for target_version and target_clones in aarch64 as it is now spec compliant. gcc/ChangeLog: * config/aarch64/aarch64.cc (aarch64_process_target_version_attr): Remove warning. * config/aarch64/aarch64.opt: Mark -Wno-expe

[PATCH v10 12/13] c: aarch64: Add FMV diagnostic tests.

2025-08-28 Thread alfie.richards
From: Alfie Richards Adds some aarch64 C fmv diagnostic tests. This mostly tests C front end code, but has to be target specific at FMV is requires specifying target extensions. gcc/testsuite/ChangeLog: * gcc.target/aarch64/mv-and-mvc-error1.c: New test. * gcc.target/aarch64/mv

[PATCH v10 11/13] c: Add target_version attribute support.

2025-08-28 Thread alfie.richards
From: Alfie Richards This commit introduces support for the target_version attribute in the c frontend, following the behavior defined in the Arm C Language Extension. Key changes include: - During pushdecl, the compiler now checks whether the current symbol is part of a multiversioned set.

[PATCH v10 07/13] c++: Refactor FMV frontend conflict and merging logic and hooks.

2025-08-28 Thread alfie.richards
From: Alfie Richards This change refactors FMV handling in the frontend to allows greater reasoning about versions in shared code. This is needed for allowing target_clones and target_versions to be used together in a function set, as there is then two distinct concerns when encountering two dec

[PATCH v10 08/13] fmv: Support mixing of target_clones and target_version.

2025-08-28 Thread alfie.richards
From: Alfie Richards Add support for a FMV set defined by a combination of target_clones and target_version definitions. Additionally, change is_function_default_version to consider a function declaration annotated with target_clones containing default to be a default version. Lastly, add suppo

[PATCH v10 03/13] riscv: Refactor riscv target parsing to take string_slice.

2025-08-28 Thread alfie.richards
From: Alfie Richards This is a quick refactor of the riscv target processing code to take a string_slice rather than a decl. The reason for this is to enable it to work with target_clones where merging logic requires reasoning about each version string individually in the front end. This refact

[PATCH v10 09/13] aarch64: testsuite: Add diagnostic tests for Aarch64 FMV.

2025-08-28 Thread alfie.richards
From: Alfie Richards Add tests covering many FMV errors for Aarch64, including redeclaration, and mixing target_clones and target_versions. gcc/testsuite/ChangeLog: * g++.target/aarch64/mv-and-mvc-error1.C: New test. * g++.target/aarch64/mv-and-mvc-error2.C: New test. *

[PATCH v10 05/13] fmv: c++: Change target_version semantics to follow ACLE specification.

2025-08-28 Thread alfie.richards
From: Alfie Richards This patch changes the semantics of target_version and target_clones attributes to match the behavior described in the Arm C Language extension. The changes to behavior are: - The scope and signature of an FMV function set is now that of the default version. - The FMV res

[PATCH v10 06/13] c: c++: Add target_[version/clones] to decl diagnostics formatting.

2025-08-28 Thread alfie.richards
From: Alfie Richards Adds the target_version and target_clones attributes to diagnostic messages for target_version semantics. This is because the target_version/target_clones attributes affect the identity of the decls, so need to be represented in diagnostics for them. This also requires maki

[PATCH v10 13/13] fmv: Redirect to specific target

2025-08-28 Thread alfie.richards
From: Alfie Richards Adds an optimisation in FMV to redirect to a specific target if possible. A call is redirected to a specific target if both: - the caller can always call the callee version - and, it is possible to rule out all higher priority versions of the callee fmv set. That is estabi

[PATCH v10 00/13] c: c++: FMV refactor, C FMV support and ACLE compliance

2025-08-28 Thread alfie.richards
From: Alfie Richards Hi all, Thanks again for all the work reviewing this series and for the feedback. This revision implements the changes requested by Jason and Richard S, and rebase changes for Richards riscv backend location_t changes. Changes since V9: - Rebase changes from Richard's risc

[PATCH v10 02/13] fmv: Refactor FMV name mangling.

2025-08-28 Thread alfie.richards
From: Alfie Richards This patch is an overhaul of how FMV name mangling works. Previously mangling logic was duplicated in several places across both target specific and independent code. This patch changes this such that all mangling is done in targetm.mangle_decl_assembler_name (including for t

[PATCH v10 04/13] fmv: c++: Add check_target_clone hook for filtering target_clone versions.

2025-08-28 Thread alfie.richards
From: Alfie Richards This patch introduces the TARGET_CHECK_TARGET_CLONE_VERSION hook which is used to determine if a target_clones version string parses. The hook has a flag to enable emitting diagnostics. This is as specified in the Arm C Language Extension. The purpose of this is to be able

[PATCH v10 01/13] cgraph: Add clone_identifier function.

2025-08-28 Thread alfie.richards
From: Alfie Richards This is similar to clone_function_name and its siblings but takes an identifier tree node rather than a function declaration. This is to be used in conjunction with the identifier node stored in cgraph_function_version_info::assembler_name to mangle FMV functions in later pa

[committed] Regenerate aarch64.opt.urls

2025-01-21 Thread alfie.richards
This updates aarch64.opt.urls after my patch earlier today. Pushing directly as it;s an obvious fix. gcc/ChangeLog: * config/aarch64/aarch64.opt.urls: Regenerate --- gcc/config/aarch64/aarch64.opt.urls | 3 +++ 1 file changed, 3 insertions(+) diff --git a/gcc/config/aarch64/aarch64.op

[PATCH v5 0/1] FMV AArch64 warning

2025-01-17 Thread alfie.richards
From: Alfie Richards Appologies, forgot to commit my changes before sending. Alfie Richards (1): Add warning for non-spec compliant FMV in Aarch64 gcc/config/aarch64/aarch64.cc | 9 + gcc/config/aarch64/aarch64.opt | 4 gcc/doc/invoke.texi

[PATCH v5 1/1] Add warning for non-spec compliant FMV in Aarch64

2025-01-17 Thread alfie.richards
This patch adds a warning when FMV is used for Aarch64. The reasoning for this is the ACLE [1] spec for FMV has diverged significantly from the current implementation and we want to prevent potential future compatability issues. There is a patch for an ACLE compliant version of target_version an

[PATCH v4 1/1] Add warning for non-spec compliant FMV in Aarch64

2025-01-17 Thread alfie.richards
This patch adds a warning when FMV is used for Aarch64. The reasoning for this is the ACLE [1] spec for FMV has diverged significantly from the current implementation and we want to prevent potential future compatability issues. There is a patch for an ACLE compliant version of target_version an

[PATCH v4 0/1] FMV AArch64 warning

2025-01-17 Thread alfie.richards
From: Alfie Richards Hi, Thank you Richard for catching that! It's good to know about keeping it around. Rebased onto master, fixed up a new test, and addressed your comment. Kind regards, Alfie Alfie Richards (1): Add warning for non-spec compliant FMV in Aarch64 gcc/config/aarch64/aarch

[PATCH v3 0/1] FMV AArch64 warning

2025-01-17 Thread alfie.richards
From: Alfie Richards Hi both, I updated this patch as in other work I found a more natural place for this warning to be issued. I also implemented Kyrylo's suggestion to only issue the warning once. I don't yet have commit access so if this patch is okay would either of you be okay to commit i

[PATCH v3 1/1] Add warning for non-spec compliant FMV in Aarch64

2025-01-17 Thread alfie.richards
This patch adds a warning when FMV is used for Aarch64. The reasoning for this is the ACLE [1] spec for FMV has diverged significantly from the current implementation and we want to prevent potential future compatability issues. There is a patch for an ACLE compliant version of target_version an

[PATCH v2] Add warning for non-spec compliant FMV in Aarch64

2025-01-09 Thread alfie.richards
This patch adds a warning when FMV is used for Aarch64. The reasoning for this is the ACLE [1] spec for FMV has diverged significantly from the current implementation and we want to prevent potential future compatability issues. There is a patch for an ACLE compliant version of target_version an

[PATCH] Add warning for use of non-spec FMV in Aarch64

2025-01-09 Thread alfie.richards
This patch adds a warning whenever FMV is used for Aarch64. The reasoning for this is the ACLE [1] spec for FMV has diverged significantly from the current implementation and we want to prevent future compatability issues. There is a patch for and ACLE compliant version of target_version and targ

[PATCH v4 1/1] C++: Add flag to generate resolver at default version implementation.

2024-12-05 Thread alfie.richards
This patch adds the TARGET_CREATE_FMV_DISPATCHER_AT_DEFAULT_IMPL flag which changes FMV behavior for target_version functions to match the Arm C Language Extension. The functional differences consist of: 1. Generating the resolver for the dispatched symbol at the site of the default version de

[PATCH v4 0/1] C++: Add flag to generate resolver at default version implementation

2024-12-05 Thread alfie.richards
From: Alfie Richards Hi Jason, Thank you for the feedback! Hopefully that is all addressed in this version. Again regtested and I think this version is functionally identical to the previous. Kind regards, Alfie Richards Alfie Richards (1): C++: Add flag to generate resolver at default ver

[PATCH v3 1/1] CPP: Add flag to generate resolver at default version implementation.

2024-11-26 Thread alfie.richards
This patch adds the TARGET_CREATE_FMV_DISPATCHER_AT_DEFAULT_IMPL flag which changes FMV behavior for target_version functions to match the Arm C Language Extension. The functional differences consist of: 1. Generating the resolver for the dispatched symbol at the site of the default version de

[PATCH v3 0/1] CPP: Add flag to generate resolver at default version implementation.

2024-11-26 Thread alfie.richards
From: Alfie Richards Hello, I have changed this patch to not rely on the C multiversion patch. I still plan to get that patch up eventually, but I think it requires some more work and feedback. This patch now just changes the FMV dispatcher generation for Aarch64 to comply with the ACLE. If po

[PATCH v4 1/1] C: Support Function multiversioning in the C front end

2024-11-15 Thread alfie.richards
This patch adds support for `target_version` function multiversioning to the C frontend, specifically intended for enabling this for Aarch64 targets. The functionality and behavior matches the CPP frontend. Which is to say it is not ACLE compliant, as I have another patch achieving this. The maj

[PATCH v4 0/1] C: Support Function multiversioning in the C front end

2024-11-15 Thread alfie.richards
From: Alfie Richards Hi Joseph and all, I worked through Josephs feedback, and as I fixed certain issues I came to the conclusion he was correct that a rethink was required. I reworked this to only have the one FMV binding for each function set which gets replaced with the dispatched symbol dec

[PATCH v2] C and CPP: Add flag to generate resolver at default version implementation.

2024-11-05 Thread alfie.richards
Hi all, Updating this patch to rebase ontop of the new version of the C FMV patch. As I mentioned in that series, we are very keen to get ACLE Compliant FMV support for Aarch64 in for GCC 15. I am aware this is a busy period for all though. Regtested on Aarch64, X86 Bootstrapped on aarch64-none-

[PATCH v3] C: Support Function multiversionsing in the C front end

2024-11-04 Thread alfie.richards
Hi, Joseph pointed out a pretty major flaw that this previously did not merge fmv declarations and definitons or check properly for duplicate definitons. I rewrote the fmv logic and moved it to pushdecl resulting in a patch that I much prefer. The logic in pushdecl now detects the FMV case and a

[PATCH] C and CPP: Add flag to generate resolver at default version implementation.

2024-10-30 Thread alfie.richards
Hi all, This patch adds the TARGET_CREATE_FMV_DISPATCHER_AT_DEFAULT_IMPL hook which changes FMV behavior for target_version functions to match the Arm C Language Extension. The functional differences consist of: 1. Generating the resolver for the dispatched symbol at the site of the default ve

[PATCH v2 0/1] Support for FMV in C front end.

2024-10-24 Thread alfie.richards
From: Alfie Richards This update serves to provide a minor cleanup and to CC in relevant maintainers. Additionally, I looked into the behavior of FMV on x86 with this patch and found the assembly looks reasonable, however the assembler produces an error for duplicate definitons so have left this

[PATCH v2 1/1] C: Support Function multiversionsing in the C front end

2024-10-24 Thread alfie.richards
This patch adds support for `target_version` function multiversioning to the C frontend, specifically intended for enabling this for Aarch64 targets. The functionality and behavior matches the CPP frontend. This is likely to need to be changed later down the line for Aarch64 targets to match the

[PATCH] [PATCH] C: Support target_version FMV for the C front end

2024-10-22 Thread alfie.richards
From: Alfie Richards This patch adds support for `target_version` function multiversioning to the C frontend. The functionality and behavior matches the CPP frontend. This is likely to need to be changed later down the line for the Aarch64 backend to match the ACLE but that is future work. Note

[PATCH v1 2/2] Aarch64, bugfix: Fix NEON bigendian addp intrinsic [PR114890]

2024-07-03 Thread alfie.richards
This change removes code that switches the operands in bigendian mode erroneously. This fixes the related test also. gcc/ChangeLog: PR target/114890 * config/aarch64/aarch64-simd.md: Remove bigendian operand swap. gcc/testsuite/ChangeLog: PR target/114890 * gcc

[PATCH v1 1/2] Aarch64: Add test for non-commutative SIMD intrinsic

2024-07-03 Thread alfie.richards
This adds a test for non-commutative SIMD NEON intrinsics. Specifically addp is non-commutative and has a bug in the current big-endian implementation. gcc/testsuite/ChangeLog: * gcc.target/aarch64/vector_intrinsics_asm.c: New test. --- .../aarch64/vector_intrinsics_asm.c | 3

[PATCH v1 0/2] Aarch64: addp NEON big-endian fix [PR114890]

2024-07-03 Thread alfie.richards
From: Alfie Richards Hi All, This fixes a case where the operands for the addp NEON intrinsic were erroneously swapped. Regtested on aarch64-unknown-linux-gnu Ok for master and GCC14.2? Kind regards, Alfie Richards Alfie Richards (2): Aarch64: Add test for non-commutative SIMD intrinsic