public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Tamar Christina <tnfchris@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r14-4714] middle-end: ifcvt: Allow any const IFN in conditional blocks Date: Wed, 18 Oct 2023 08:54:50 +0000 (GMT) [thread overview] Message-ID: <20231018085450.9DC893858404@sourceware.org> (raw) https://gcc.gnu.org/g:b0fe8f2f960d746e61debd61655f231f503bccaa commit r14-4714-gb0fe8f2f960d746e61debd61655f231f503bccaa Author: Tamar Christina <tamar.christina@arm.com> Date: Wed Oct 18 09:33:30 2023 +0100 middle-end: ifcvt: Allow any const IFN in conditional blocks When ifcvt was initially added masking was not a thing and as such it was rather conservative in what it supported. For builtins it only allowed C99 builtin functions which it knew it can fold away. These days the vectorizer is able to deal with needing to mask IFNs itself. vectorizable_call is able vectorize the IFN by emitting a VEC_PERM_EXPR after the operation to emulate the masking. This is then used by match.pd to conver the IFN into a masked variant if it's available. For these reasons the restriction in ifconvert is no longer require and we needless block vectorization when we can effectively handle the operations. Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. Note: This patch is part of a testseries and tests for it are added in the AArch64 patch that adds supports for the optab. gcc/ChangeLog: PR tree-optimization/109154 * tree-if-conv.cc (if_convertible_stmt_p): Allow any const IFN. Diff: --- gcc/tree-if-conv.cc | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/gcc/tree-if-conv.cc b/gcc/tree-if-conv.cc index 3b4238831c3e..edce842db940 100644 --- a/gcc/tree-if-conv.cc +++ b/gcc/tree-if-conv.cc @@ -1107,17 +1107,21 @@ if_convertible_stmt_p (gimple *stmt, vec<data_reference_p> refs) case GIMPLE_CALL: { + /* There are some IFN_s that are used to replace builtins but have the + same semantics. Even if MASK_CALL cannot handle them vectorable_call + will insert the proper selection, so do not block conversion. */ + int flags = gimple_call_flags (stmt); + if ((flags & ECF_CONST) + && !(flags & ECF_LOOPING_CONST_OR_PURE) + && gimple_call_combined_fn (stmt) != CFN_LAST) + return true; + tree fndecl = gimple_call_fndecl (stmt); if (fndecl) { /* We can vectorize some builtins and functions with SIMD "inbranch" clones. */ - int flags = gimple_call_flags (stmt); struct cgraph_node *node = cgraph_node::get (fndecl); - if ((flags & ECF_CONST) - && !(flags & ECF_LOOPING_CONST_OR_PURE) - && fndecl_built_in_p (fndecl)) - return true; if (node && node->simd_clones != NULL) /* Ensure that at least one clone can be "inbranch". */ for (struct cgraph_node *n = node->simd_clones; n != NULL; @@ -1129,6 +1133,7 @@ if_convertible_stmt_p (gimple *stmt, vec<data_reference_p> refs) return true; } } + return false; }
reply other threads:[~2023-10-18 8:54 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20231018085450.9DC893858404@sourceware.org \ --to=tnfchris@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).