From patchwork Wed Dec 20 02:53:53 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexandre Oliva X-Patchwork-Id: 1878352 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; secure) header.d=adacore.com header.i=@adacore.com header.a=rsa-sha256 header.s=google header.b=XxRmg2Eo; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4Svynr4Dqqz20LV for ; Wed, 20 Dec 2023 13:54:24 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 27201385E443 for ; Wed, 20 Dec 2023 02:54:22 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-oa1-x32.google.com (mail-oa1-x32.google.com [IPv6:2001:4860:4864:20::32]) by sourceware.org (Postfix) with ESMTPS id 40A11385803B for ; Wed, 20 Dec 2023 02:54:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 40A11385803B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 40A11385803B Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:4860:4864:20::32 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703040850; cv=none; b=rbHEv7tV1KXZCZzOSxHa19sEDYiH5skflEuYGi6xIVCLKZqQtdi/rgvL49i4iBmyIqfBdnSAdLunc0AmzhT2cfVAv940Q0uDJpT5xWTbtQkrhO0995NPOadu5VzMWmYnxdcYVC7hY5HmkpSMn3hZCQfMMEsaDp9YmFPVb8BMQLU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703040850; c=relaxed/simple; bh=pUxUraDdLyUEj6rn5uaGNS2a/UyfM0qDTjgJCwuxF9M=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=p8vD/i9w7yMYP8AoF/LQjOFH7w87ZEOCIlGhkFeS5e9wsJ9D38RYDRyLn4sEKu7QTS5y4cfiOtANB+pgMDsgsOsMffptVu0xM++tgghZv+LP2ketCPrkokn42VJyLYFJDktqYPwvifYGOAi2cy7zj41XvpTzLCF++kpeV2nNeqs= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-20364459774so3076999fac.2 for ; Tue, 19 Dec 2023 18:54:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1703040847; x=1703645647; darn=gcc.gnu.org; h=mime-version:user-agent:message-id:date:organization:subject:to :from:from:to:cc:subject:date:message-id:reply-to; bh=vaJbX2/j5ijyP9Tg7j/2fBoyY8Me6gElH5ANfYJJqjU=; b=XxRmg2EoQNUEvgXMCNd6OBkizHpq/ThMEU0cLFFo+3Tn/LXZVX3+4SPBVz0h2TrF95 MmfWpF1nHmdah7TqJlIsRHnlr3+UYey4moCOe9SyaKEmT2gScs3cd5wFyLHpz3bUTdKL CKFuD1F0896wZKSXrK4MFSOkhjBkzLzOrfA2Dl/g01dnmdQZIMLQH4TtkGp4IT5x8oD0 jYyM+BTa3Qgab7WLV0Jk5P2ppDjHUOrsYaDu0KjSkzMjTxbmZ7Sgv3gqWaKsqnWuUq/9 BQa6nq7/CXyMC8/2hNshl58QFY1AG/8zdpXmPG7eOATBdgfS5RF3YuhlwjRdaAK436xa KuBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703040847; x=1703645647; h=mime-version:user-agent:message-id:date:organization:subject:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vaJbX2/j5ijyP9Tg7j/2fBoyY8Me6gElH5ANfYJJqjU=; b=YKdp7aj5bTbvQw+uQRU5KrrsZsfz62ScNGOEYR8TBAennuVh0y5g1m8GvJiyeod2Va hnQ5Uktebp9Nzi0lO1cW0pAOXUnD3F9yZBu+cmH98XlFA7s0kdl4JUHkVqIPSyl6SWc7 sEWZBIbHHxGDOhOtP3JnzKwJYjNDnHXEx7TjBfQUBKpUQ7RXRmDgqTA1yuqfNTaAl7rG HH9RVOnmP5jzQ2+gAOm++888sFtKzRkoEv0XYHoeBy68ougyd/yHkdeaLa7Djku/ZkaN GKym8PmrBthsUgyn/qi2QydY7LVCy+zubfTyxPgiXCdA7ZYGymOKlbkmn7LI2P1uQ7GQ AE8g== X-Gm-Message-State: AOJu0YwEoiJmHm4ZQHAilA59T1SClGF4uRAZeCwWmvdCbfoMoTQ19JvN SdyJ+sd6nEQThxEHWMc1Tj7OEragyuuyPTSCndmh5A== X-Google-Smtp-Source: AGHT+IGE+Q64MQqrvC0QLot6WYYHvlLrg4bIIdZ/vuq34jbzh00nNLDDmMqSLJfgFVD2534ItC9/vg== X-Received: by 2002:a05:6358:2908:b0:170:4322:4040 with SMTP id y8-20020a056358290800b0017043224040mr24979228rwb.17.1703040847485; Tue, 19 Dec 2023 18:54:07 -0800 (PST) Received: from free.home ([2804:7f1:2080:dd67:1c01:ac85:7bb4:256d]) by smtp.gmail.com with ESMTPSA id ds17-20020a17090b08d100b0028b21d24ba6sm2375591pjb.15.2023.12.19.18.54.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Dec 2023 18:54:06 -0800 (PST) Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 3BK2rrbE674604 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 19 Dec 2023 23:53:54 -0300 From: Alexandre Oliva To: gcc-patches@gcc.gnu.org Subject: [PATCH] -finline-stringops: allow expansion into edges [PR113002] Organization: Free thinker, does not speak for AdaCore Date: Tue, 19 Dec 2023 23:53:53 -0300 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 X-Spam-Status: No, score=-12.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, WEIRD_QUOTING autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Builtin expanders for memset and memcpy may involve conditionals and loops, but their sequences may be end up emitted in edges. Alas, commit_one_edge_insertion rejects sequences that end with a jump, a requirement that makes sense for insertions after expand, but not so much during expand. During expand, jumps may appear in the middle of the insert sequence as much as in the end, and it's only after committing edge insertions out of PHI nodes that we go through the entire function splitting blocks where needed, so relax the assert in commit_one_edge_insertion so that jumps are accepted during expand even at the end of the sequence. Regstrapping on x86_64-linux-gnu, after testing the testcase with a cross compiler to ppc64le-linux-gnu. Ok to install? Builtin expanders for memset and memcpy may involve conditionals and loops, but their sequences may be end up emitted in edges. Alas, commit_one_edge_insertion rejects sequences that end with a jump, a requirement that makes sense for insertions after expand, but not so much during expand. During expand, jumps may appear in the middle of the insert sequence as much as in the end, and it's only after committing edge insertions out of PHI nodes that we go through the entire function splitting blocks where needed, so relax the assert in commit_one_edge_insertion so that jumps are accepted during expand even at the end of the sequence. for gcc/ChangeLog PR rtl-optimization/113002 * cfgrtl.cc (commit_one_edge_insertion): Tolerate jumps in the inserted sequence during expand. for gcc/testsuite/ChangeLog PR rtl-optimization/113002 * gcc.dg/vect/pr113002.c: New. --- gcc/cfgrtl.cc | 8 +++++++- gcc/testsuite/gcc.dg/vect/pr113002.c | 13 +++++++++++++ 2 files changed, 20 insertions(+), 1 deletion(-) create mode 100644 gcc/testsuite/gcc.dg/vect/pr113002.c diff --git a/gcc/cfgrtl.cc b/gcc/cfgrtl.cc index 2a3f853eed59b..437eb3a86d5c2 100644 --- a/gcc/cfgrtl.cc +++ b/gcc/cfgrtl.cc @@ -2092,7 +2092,13 @@ commit_one_edge_insertion (edge e) delete_insn (before); } else - gcc_assert (!JUMP_P (last)); + /* Some builtin expanders, such as those for memset and memcpy, + may generate loops and conditionals, and those may get emitted + into edges. That's ok while expanding to rtl, basic block + boundaries will be identified and split afterwards. ??? Need + we check whether the destination labels of any inserted jumps + are also part of the inserted sequence? */ + gcc_assert (!JUMP_P (last) || currently_expanding_to_rtl); } /* Update the CFG for all queued instructions. */ diff --git a/gcc/testsuite/gcc.dg/vect/pr113002.c b/gcc/testsuite/gcc.dg/vect/pr113002.c new file mode 100644 index 0000000000000..186710f64b422 --- /dev/null +++ b/gcc/testsuite/gcc.dg/vect/pr113002.c @@ -0,0 +1,13 @@ +/* { dg-do compile } */ +/* { dg-require-effective-target int128 } */ +/* { dg-options "-finline-stringops -Os" } */ + +typedef __int128 v64u128 __attribute__((vector_size(64))); +int c; +v64u128 u; +void foo() { + if (c) + u = (v64u128){0}; + else + u = (v64u128){1}; +}