aboutsummaryrefslogtreecommitdiff
path: root/gcc/config/aarch64
diff options
context:
space:
mode:
authorRichard Sandiford <richard.sandiford@arm.com>2024-10-09 13:57:36 +0100
committerRichard Sandiford <richard.sandiford@arm.com>2024-10-09 13:57:36 +0100
commitfee3adbac055c3ff2649fed866c66d44ebfcbe90 (patch)
tree2a5795a3ebfd6e79383ced2a49766cd58d5b9fe8 /gcc/config/aarch64
parentb94331d9a3f7efb451bfad9db0fda162d3c46748 (diff)
downloadgcc-fee3adbac055c3ff2649fed866c66d44ebfcbe90.zip
gcc-fee3adbac055c3ff2649fed866c66d44ebfcbe90.tar.gz
gcc-fee3adbac055c3ff2649fed866c66d44ebfcbe90.tar.bz2
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.
Diffstat (limited to 'gcc/config/aarch64')
-rw-r--r--gcc/config/aarch64/aarch64-sve-builtins.cc2
1 files changed, 1 insertions, 1 deletions
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)
{