Alex Coplan <alex.cop...@arm.com> writes:
> Hi all,
>
> Here is a v2 patch which provides a more obviously fake answer to
> TARGET_BUILTIN_DECL: this can hopefully go in for GCC 11. For GCC 12, it
> seems that we should consider removing the target hook.
>
> Original patch:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566405.html
>
> ---
>
> As discussed in the PR, we currently have two different numbering
> schemes for SVE builtins: one for C, and one for C++. This is
> problematic for LTO, where we end up getting confused about which
> intrinsic we're talking about. This patch inserts placeholders into the
> registered_functions vector to ensure that there is a consistent
> numbering scheme for both C and C++.
>
> This patch uses integer_zero_node as a placeholder node instead of
> building a function decl. This is safe because the node is only returned
> by the TARGET_BUILTIN_DECL hook, which (on AArch64) is only used for
> validation when builtin decls are streamed into lto1.
>
> Bootstrapped and regtested on aarch64-linux-gnu, OK for trunk?
>
> Thanks,
> Alex
>
> gcc/ChangeLog:
>
>       PR target/99216
>       * config/aarch64/aarch64-sve-builtins.cc
>       (function_builder::add_function): Add placeholder_p argument, use
>       placeholder decls if this is set.
>       (function_builder::add_unique_function): Instead of conditionally adding
>       direct overloads, unconditionally add either a direct overload or a
>       placeholder.
>       (function_builder::add_overloaded_function): Set placeholder_p if we're
>       using C++ overloads. Use the obstack for string storage instead
>       of relying on the tree nodes.
>       (function_builder::add_overloaded_functions): Don't return early for
>       m_direct_overloads: we need to add placeholders.
>       * config/aarch64/aarch64-sve-builtins.h
>       (function_builder::add_function): Add placeholder_p argument.
>
> gcc/testsuite/ChangeLog:
>
>       PR target/99216
>       * g++.target/aarch64/sve/pr99216.C: New test.

OK, thanks, and sorry for the delay in reviewing.

Richard

Reply via email to