From fee3adbac055c3ff2649fed866c66d44ebfcbe90 Mon Sep 17 00:00:00 2001 From: Richard Sandiford Date: Wed, 9 Oct 2024 13:57:36 +0100 Subject: aarch64: Fix SVE ACLE gimple folds for C++ LTO [PR116629] The SVE ACLE code has two ways of handling overloaded functions. One, used by C, is to define a single dummy function for each unique overloaded name, with resolve_overloaded_builtin then resolving calls to real non-overloaded functions. The other, used by C++, is to define a separate function for each individual overload. The builtins harness assigns integer function codes programmatically. However, LTO requires it to use the same assignment for every translation unit, regardless of language. This means that C++ TUs need to create (unused) slots for the C overloads and that C TUs need to create (unused) slots for the C++ overloads. In many ways, it doesn't matter whether the LTO frontend itself uses the C approach or the C++ approach to defining overloaded functions, since the LTO frontend never has to resolve source-level overloading. However, the C++ approach of defining a separate function for each overload means that C++ calls never need to be redirected to a different function. Calls to an overload can appear in the LTO dump and survive until expand. In contrast, calls to C's dummy overload functions are resolved by the front end and never survive to LTO (or expand). Some optimisations work by moving between sibling functions, such as _m to _x. If the source function is an overload, the expected destination function is too. The LTO frontend needs to define C++ overloads if it wants to do this optimisation properly for C++. The PR is about a tree checking failure caused by trying to use a stubbed-out C++ overload in LTO. Dealing with that by detecting the stub (rather than changing which overloads are defined) would have turned this from an ice-on-valid to a missed optimisation. In future, it would probably make sense to redirect overloads to non-overloaded functions during gimple folding, in case that exposes more CSE opportunities. But it'd probably be of limited benefit, since it should be rare for code to mix overloaded and non-overloaded uses of the same operation. It also wouldn't be suitable for backports. gcc/ PR target/116629 * config/aarch64/aarch64-sve-builtins.cc (function_builder::function_builder): Use direct overloads for LTO. gcc/testsuite/ PR target/116629 * gcc.target/aarch64/sve/acle/general/pr106326_2.c: New test. --- gcc/config/aarch64/aarch64-sve-builtins.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'gcc/config/aarch64') diff --git a/gcc/config/aarch64/aarch64-sve-builtins.cc b/gcc/config/aarch64/aarch64-sve-builtins.cc index 5ff4621..e7c703c 100644 --- a/gcc/config/aarch64/aarch64-sve-builtins.cc +++ b/gcc/config/aarch64/aarch64-sve-builtins.cc @@ -1283,7 +1283,7 @@ function_builder::function_builder (handle_pragma_index pragma_index, bool function_nulls) { m_overload_type = build_function_type (void_type_node, void_list_node); - m_direct_overloads = lang_GNU_CXX (); + m_direct_overloads = lang_GNU_CXX () || in_lto_p; if (initial_indexes[pragma_index] == 0) { -- cgit v1.1