Message ID | 8f71494f-c3c7-e782-6e57-281eb4c8a393@yahoo.co.jp |
---|---|
State | New |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> 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 C79453954C40 for <patchwork@sourceware.org>; Tue, 31 May 2022 03:37:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C79453954C40 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1653968260; bh=QIvU+uJp+KOhXf+6hNahCMSOfAY3RIIeBv+HcKk+tXQ=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=Ls3Qywl6p78t/yMnyGLZszLX5lTwU1yoEFPfpC/WEWq0jbvfW69sbM3gnVjXypm+e oRQtoyd1Z8wvrKBFhxTQtnNormlRXXZAdU//ZNFFREiwh07BFCslFd17xbAui4odA1 9w4CEHdCRlb9sp4zocOOb2emyVhXQNgbQcoXQQok= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from nh505-vm1.bullet.mail.kks.yahoo.co.jp (nh505-vm1.bullet.mail.kks.yahoo.co.jp [183.79.57.103]) by sourceware.org (Postfix) with SMTP id 26CED3954437 for <gcc-patches@gcc.gnu.org>; Tue, 31 May 2022 03:37:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 26CED3954437 Received: from [183.79.100.139] by nh505.bullet.mail.kks.yahoo.co.jp with NNFMP; 31 May 2022 03:37:06 -0000 Received: from [183.79.100.136] by t502.bullet.mail.kks.yahoo.co.jp with NNFMP; 31 May 2022 03:37:06 -0000 Received: from [127.0.0.1] by omp505.mail.kks.yahoo.co.jp with NNFMP; 31 May 2022 03:37:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 666908.88799.bm@omp505.mail.kks.yahoo.co.jp Received: (qmail 51201 invoked by alias); 31 May 2022 03:37:06 -0000 Received: from unknown (HELO ?192.168.2.3?) (175.177.45.170 with ) by smtp6005.mail.ssk.ynwp.yahoo.co.jp with SMTP; 31 May 2022 03:37:06 -0000 X-YMail-JAS: 4VYTHzYVM1kdmMa3z1oCj3yZiV4tldLp.pI0hYugMVvin5u071b7yWiqS7YOe7JCckfSGdTgkoE2TXDM3NRZFxpHYGBZNbkXai82Dvh4jKaPd6z7nNL2PHsMjduMurenkZo83xTqcw-- X-Apparently-From: <jjsuwa_sys3175@yahoo.co.jp> X-YMail-OSG: 2iHHUawVM1mFLxPcnUqxtCnz2GeqkhYfmmfpsGmE4JbGHGw m0mbGikEd1GChAqPbBE7IWcqfoE1m40Z5HC2LPJeAyfECRHTwPIRtp_J7we0 SH_o7wj0hyTmH0D0Z40obmhS9MsqkJbi38iywxMq6zYW453wnwryKCWhGQem Eq2jAorlUf69ch4vn_5JH7f5.72nV783DZfKMg3Q8NgSUusOZtVzY.NtbJ2k UCi_9wPBlABJwrQ6CYmSut9UVEUtQfvvevsbM9Ltw.L7XSPG8Wb6SXSWKRl9 iHqz_UZek2kMLc8A.llry.gX10w__TJA0AB_Ws95OAEYtRgfMf5BRKv.nnfv cxJBBCdEdSaqAZxJ543U1sw22qaSTuQGm7tmelBZrQgIYsW__.szUzpZh.Hf HL5nxGdBcPeoh5gm3ZvTrHJWU8GdD7_.BEKKx8jTwUV7FhWnME9tzYslKgSh ARz0ALfJIyLNxibPOkenIHUP6WTcpWhy_y7DvDJ68LzkbbYaG2OtXv8p._aL kB.wX5eun2ohBXEKz2TbYuOpYYFXjA5DJgErzpeUNsWSn39dIl22L1BzH5fT Fz34PxYyxr9Q.FFIbVdEqI3kffHKUmOZKsECovKx6kc6UInCINl4ik1YZenF e15VSjN4zfBrItuCQEVp_kR5mBnuVYZRs6oEx2tW7yMWkaOP1LQpEb7s0zwB mGUuBw3LdDGYmm8LalrcN8Xj86BaQ8jvVpglbfMu5DyH8u7FsdXWFVS_jJg8 K77jnqwwToFtuRa26X8cAcZL10uXZRHWokcxqBm9lFNvZivrSqogHdjLBE3r 4kSodVy10CiSmeBg2jfEdMqdecRjGEaaj6p_cRlUriFwWE.TI2oaheujoGA1 DS6hEuCqfeuiwXw4Gip7fcy_W_7xra7ScD9fQB139SRvzj7x8fE6f8BePhrW lP3u1OBraxW80009T Message-ID: <8f71494f-c3c7-e782-6e57-281eb4c8a393@yahoo.co.jp> Date: Tue, 31 May 2022 12:35:05 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Content-Language: en-US To: GCC Patches <gcc-patches@gcc.gnu.org> Subject: [PATCH] expr.cc: Optimize if char array initialization consists of all zeros Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-12.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, 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 <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Takayuki 'January June' Suwa via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Takayuki 'January June' Suwa <jjsuwa_sys3175@yahoo.co.jp> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
expr.cc: Optimize if char array initialization consists of all zeros
|
|
Commit Message
Takayuki 'January June' Suwa
May 31, 2022, 3:35 a.m. UTC
Hi all, In some targets, initialization code for char array may be split into two parts even if the initialization consists of all zeros: /* example */ extern void foo(char*); void test(void) { char a[256] = { 0, 0, 0, 0, 0, 0, 0, 0, 0 }; foo(a); } ;; Xtensa (xtensa-lx106) .LC0: .string "" .string "" .string "" .string "" .string "" .string "" .string "" .string "" .string "" .string "" .zero 246 test: movi a9, 0x110 sub sp, sp, a9 l32r a3, .LC1 movi.n a4, 0xa mov.n a2, sp s32i a0, sp, 268 call0 memcpy movi a4, 0xf6 movi.n a3, 0 addi.n a2, sp, 10 call0 memset mov.n a2, sp call0 foo l32i a0, sp, 268 movi a9, 0x110 add.n sp, sp, a9 ret.n ;; H8/300 (-mh -mint32) .LC0: .string "" .string "" .string "" .string "" .string "" .string "" .string "" .string "" .string "" .string "" .zero 246 _test: sub.l #256,er7 sub.l er2,er2 add.b #10,r2l mov.l #.LC0,er1 mov.l er7,er0 jsr @_memcpy sub.l er2,er2 add.b #246,r2l sub.l er1,er1 sub.l er0,er0 add.b #10,r0l add.l er7,er0 jsr @_memset mov.l er7,er0 jsr @_foo add.l #256,er7 rts i386 target (both 32 and 64bit) does not show such behavior. gcc/ChangeLog: * expr.cc (store_expr): Add check if the initialization content consists of all zeros. --- gcc/expr.cc | 7 +++++++ 1 file changed, 7 insertions(+)
Comments
On Tue, May 31, 2022 at 5:37 AM Takayuki 'January June' Suwa via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > Hi all, > > In some targets, initialization code for char array may be split into two > parts even if the initialization consists of all zeros: > > /* example */ > extern void foo(char*); > void test(void) { > char a[256] = { 0, 0, 0, 0, 0, 0, 0, 0, 0 }; > foo(a); > } > > ;; Xtensa (xtensa-lx106) > .LC0: > .string "" > .string "" > .string "" > .string "" > .string "" > .string "" > .string "" > .string "" > .string "" > .string "" > .zero 246 > test: > movi a9, 0x110 > sub sp, sp, a9 > l32r a3, .LC1 > movi.n a4, 0xa > mov.n a2, sp > s32i a0, sp, 268 > call0 memcpy > movi a4, 0xf6 > movi.n a3, 0 > addi.n a2, sp, 10 > call0 memset > mov.n a2, sp > call0 foo > l32i a0, sp, 268 > movi a9, 0x110 > add.n sp, sp, a9 > ret.n > > ;; H8/300 (-mh -mint32) > .LC0: > .string "" > .string "" > .string "" > .string "" > .string "" > .string "" > .string "" > .string "" > .string "" > .string "" > .zero 246 > _test: > sub.l #256,er7 > sub.l er2,er2 > add.b #10,r2l > mov.l #.LC0,er1 > mov.l er7,er0 > jsr @_memcpy > sub.l er2,er2 > add.b #246,r2l > sub.l er1,er1 > sub.l er0,er0 > add.b #10,r0l > add.l er7,er0 > jsr @_memset > mov.l er7,er0 > jsr @_foo > add.l #256,er7 > rts > > i386 target (both 32 and 64bit) does not show such behavior. > > gcc/ChangeLog: > > * expr.cc (store_expr): Add check if the initialization content > consists of all zeros. > --- > gcc/expr.cc | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/gcc/expr.cc b/gcc/expr.cc > index 7197996cec7..f94310dc7b9 100644 > --- a/gcc/expr.cc > +++ b/gcc/expr.cc > @@ -6015,6 +6015,7 @@ store_expr (tree exp, rtx target, int call_param_p, > rtx dest_mem; > tree str = TREE_CODE (exp) == STRING_CST > ? exp : TREE_OPERAND (TREE_OPERAND (exp, 0), 0); > + char ch; > > exp_len = int_expr_size (exp); > if (exp_len <= 0) > @@ -6032,6 +6033,12 @@ store_expr (tree exp, rtx target, int call_param_p, > } > > str_copy_len = TREE_STRING_LENGTH (str); > + /* If str contains only zeroes, no need to store to target. */ > + ch = 0; > + for (HOST_WIDE_INT i = 0; i < str_copy_len; ++i) > + ch |= TREE_STRING_POINTER (str)[i]; > + if (ch == 0) > + str_copy_len = 0; Not sure if I decipher the current code correctly but maybe we instead want to prune str_copy_len from the end for trailing \0 bytes instead of just special-casing all-zero initializers? > if ((STORE_MAX_PIECES & (STORE_MAX_PIECES - 1)) == 0) > { > str_copy_len += STORE_MAX_PIECES - 1; > -- > 2.20.1
On 5/30/2022 9:35 PM, Takayuki 'January June' Suwa via Gcc-patches wrote: > Hi all, > > In some targets, initialization code for char array may be split into two > parts even if the initialization consists of all zeros: > > /* example */ > extern void foo(char*); > void test(void) { > char a[256] = { 0, 0, 0, 0, 0, 0, 0, 0, 0 }; > foo(a); > } > > ;; Xtensa (xtensa-lx106) > .LC0: > .string "" > .string "" > .string "" > .string "" > .string "" > .string "" > .string "" > .string "" > .string "" > .string "" > .zero 246 > test: > movi a9, 0x110 > sub sp, sp, a9 > l32r a3, .LC1 > movi.n a4, 0xa > mov.n a2, sp > s32i a0, sp, 268 > call0 memcpy > movi a4, 0xf6 > movi.n a3, 0 > addi.n a2, sp, 10 > call0 memset > mov.n a2, sp > call0 foo > l32i a0, sp, 268 > movi a9, 0x110 > add.n sp, sp, a9 > ret.n > > ;; H8/300 (-mh -mint32) > .LC0: > .string "" > .string "" > .string "" > .string "" > .string "" > .string "" > .string "" > .string "" > .string "" > .string "" > .zero 246 > _test: > sub.l #256,er7 > sub.l er2,er2 > add.b #10,r2l > mov.l #.LC0,er1 > mov.l er7,er0 > jsr @_memcpy > sub.l er2,er2 > add.b #246,r2l > sub.l er1,er1 > sub.l er0,er0 > add.b #10,r0l > add.l er7,er0 > jsr @_memset > mov.l er7,er0 > jsr @_foo > add.l #256,er7 > rts > > i386 target (both 32 and 64bit) does not show such behavior. > > gcc/ChangeLog: > > * expr.cc (store_expr): Add check if the initialization content > consists of all zeros. It's not entirely clear what you're trying to accomplish. Is it the .zero which allocates space in the .rodata you're trying to remove? If so, it looks like that is already addressed on the trunk to me (I checked H8 with and without optimization). jeff
diff --git a/gcc/expr.cc b/gcc/expr.cc index 7197996cec7..f94310dc7b9 100644 --- a/gcc/expr.cc +++ b/gcc/expr.cc @@ -6015,6 +6015,7 @@ store_expr (tree exp, rtx target, int call_param_p, rtx dest_mem; tree str = TREE_CODE (exp) == STRING_CST ? exp : TREE_OPERAND (TREE_OPERAND (exp, 0), 0); + char ch; exp_len = int_expr_size (exp); if (exp_len <= 0) @@ -6032,6 +6033,12 @@ store_expr (tree exp, rtx target, int call_param_p, } str_copy_len = TREE_STRING_LENGTH (str); + /* If str contains only zeroes, no need to store to target. */ + ch = 0; + for (HOST_WIDE_INT i = 0; i < str_copy_len; ++i) + ch |= TREE_STRING_POINTER (str)[i]; + if (ch == 0) + str_copy_len = 0; if ((STORE_MAX_PIECES & (STORE_MAX_PIECES - 1)) == 0) { str_copy_len += STORE_MAX_PIECES - 1;