From patchwork Thu Jul 7 14:46:16 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jeff Law X-Patchwork-Id: 55845 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0745E3856254 for ; Thu, 7 Jul 2022 14:46:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0745E3856254 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1657205209; bh=JOZ9dYub7WF7FokkhN+TtZvIRKwl8qmc8Cjjcc/O9wo=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=SAuhXwZ+NWaPJgCAhB2l4t9UJIrw3phw3YdTAgizXAA9yklrJ5Mf6PDIepMIOO/aZ dCDF6hUI+T1t7MrQX5/HBeiud21kJqmXM4VliGcYgl32z4xuE/D8jG0DB0k36GZhbJ Qqmp+YB903wCNu6JNAeeleXFr+6XHP544pFqeuMw= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by sourceware.org (Postfix) with ESMTPS id F13363858D32 for ; Thu, 7 Jul 2022 14:46:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F13363858D32 Received: by mail-pf1-x436.google.com with SMTP id g126so5413730pfb.3 for ; Thu, 07 Jul 2022 07:46:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:from:subject:cc; bh=JOZ9dYub7WF7FokkhN+TtZvIRKwl8qmc8Cjjcc/O9wo=; b=juURPufuYXpTmRcf5B7LgPN6nqAtBUh7K6HoqKtBtODh6yBFIAFm5u1aqvuhtm+zdB e7dqf6jxTMN0nFMWKGpVN0TY50jxpWerbTe9MItV3P0F27yyvVVk7VHwxW/+kUScRouX CGppNJDkoInr/iGhn1tjBCsUGlL9dQDt862BMsBUwzfc0XiP9w34CiXzQ0w3gSrhspHN WkDKCHtTK6NWzbm96Ld6ciREtLUFMoOH0Vb7yry/iC1JHStZQPaEXDLEjqgXin2iaU13 2/GUb1ebFLiQMEPI/68s68lA4idSe9zzGrAYhfiOnh8ob6M04sxAjmO3jaedLHGtb3xk xOkQ== X-Gm-Message-State: AJIora+jwBVE0taJnLyOry1fAGhjJa2VPvOKvIxbkRC4qWQ5D5YupOKL 8tooEWf48Bcp+pjSOJ5lZq4Jp/ZJowM= X-Google-Smtp-Source: AGRyM1sQoBFNWQcYjnTcKDbJPaFwDcdmbyI5kFVEtWgNGdAGXIpInjVW5FJ40/tYx8WOGnX172hfPw== X-Received: by 2002:a17:902:cf06:b0:16b:cc33:5bce with SMTP id i6-20020a170902cf0600b0016bcc335bcemr31191709plg.152.1657205177563; Thu, 07 Jul 2022 07:46:17 -0700 (PDT) Received: from [172.31.0.204] (c-73-63-24-84.hsd1.ut.comcast.net. [73.63.24.84]) by smtp.gmail.com with ESMTPSA id s8-20020aa78d48000000b0052089e1b88esm27094074pfe.192.2022.07.07.07.46.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Jul 2022 07:46:17 -0700 (PDT) Message-ID: <446ea3de-5486-8756-47f1-7822d79c5d75@gmail.com> Date: Thu, 7 Jul 2022 08:46:16 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Content-Language: en-US To: 'GCC Patches' Subject: [RFA] Improve initialization of objects when the initializer has trailing zeros. X-Spam-Status: No, score=-8.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Jeff Law via Gcc-patches From: Jeff Law Reply-To: Jeff Law Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" This is an update to a patch originally posted by Takayuki Suwa a few months ago. When we initialize an array from a STRING_CST we perform the initialization in two steps.  The first step copies the STRING_CST to the destination.  The second step uses clear_storage to initialize storage in the array beyond TREE_STRING_LENGTH of the initializer. Takayuki's patch added a special case when the STRING_CST itself was all zeros which would avoid the copy from the STRING_CST and instead do all the initialization via clear_storage which is clearly more runtime efficient. Richie had the suggestion that instead of special casing when the entire STRING_CST was NULs  to instead identify when the tail of the STRING_CST was NULs.   That's more general and handles Takayuki's case as well. Bootstrapped and regression tested on x86_64-linux-gnu.  Given I rewrote Takayuki's patch I think it needs someone else to review rather than self-approving. OK for the trunk? Jeff * expr.cc (store_expr): Identify trailing NULs in a STRING_CST initializer and use clear_storage rather than copying the NULs to the destination array. diff --git a/gcc/expr.cc b/gcc/expr.cc index 62297379ec9..f94d46b969c 100644 --- a/gcc/expr.cc +++ b/gcc/expr.cc @@ -6087,6 +6087,17 @@ store_expr (tree exp, rtx target, int call_param_p, } str_copy_len = TREE_STRING_LENGTH (str); + + /* Trailing NUL bytes in EXP will be handled by the call to + clear_storage, which is more efficient than copying them from + the STRING_CST, so trim those from STR_COPY_LEN. */ + while (str_copy_len) + { + if (TREE_STRING_POINTER (str)[str_copy_len - 1]) + break; + str_copy_len--; + } + if ((STORE_MAX_PIECES & (STORE_MAX_PIECES - 1)) == 0) { str_copy_len += STORE_MAX_PIECES - 1;