From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) by sourceware.org (Postfix) with ESMTPS id 285993858C41 for ; Fri, 19 May 2023 16:57:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 285993858C41 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x62d.google.com with SMTP id d9443c01a7336-1ae87bde5c9so6498255ad.0 for ; Fri, 19 May 2023 09:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684515420; x=1687107420; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=67gYAoT7wCt0W5GwPhhBMT5KopO3pHV3b4nM9gmXBuo=; b=TMKjFpIdTnQD/bO2pOsDxdymwVDWXlZeA+GlDdx2gNXGZURM8UgnjHA6Isr16XOECb L4BOnqxCeoyjCDHvCDbPYWGE85cKxNNHgKvzTB4GO79LnHL0mcYCn/gs0Xx4LvkMZa+q 3lUcPv8JBC8YcIm9Mz0kAVYdFbI0fTuZdHrxjFvmlwRTlvAPZErh+a/qHb9nnx/V24mL IjP2wKGbh+TlTpVvLtTESkYLhpygkNxJadPww+y5AaWAqNsdaz409nLRLIHPvnWErMBt Mn3+Su4vSYpGUe8xV6dmlJ81TeRKVJfHBBEcmnTy32YSJ/m4NNn1s4JE2TFIYpgZmX8Z V4Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684515420; x=1687107420; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=67gYAoT7wCt0W5GwPhhBMT5KopO3pHV3b4nM9gmXBuo=; b=eTylpiYzDgKkvgX27t2kumEICWHifIuX7DqXPuB5gyiPY65W2rKQ0DGl09FNsx1ZyS aawdDhhSmjAnABUxyv6PSQHzaFIECL5bG8212Dp2KNZwF9SfdzYIkm8lS7/fD9oq+HOf +Qr08Z8hMa6dI1YlKZ0DsRDwqARk6hgvOHpiHT9SRxlqUCXEDKfzL5+I7GaQLduZuTMI YRfIeAHNdhB+vgU72+iJp+pf7w0TFNV6+r41b1GYpBMTrODjupOeEIpUNEydGXsU+ywC VJPZPz8PVrXGFKANublDp3IIk+qDr+eWEKdzg2mg1h09bqIdVtpPgX0ARPhQ8dyu910/ KIrA== X-Gm-Message-State: AC+VfDxIgTTS/gO5gmAP5nabjYanhUhMYUrLLf01Wo9Djz5Xxp9GEwZI h2eMd1KdCPf4mQYbK7NNnsk= X-Google-Smtp-Source: ACHHUZ40sSzy7G3nqUgSSPUqkEKQgyO4dqgkL2dZWSTcHOvX/TV3sPGAhGMgF0OViVKW3KRBs1+hRQ== X-Received: by 2002:a17:902:6bcb:b0:1ae:5fb0:4256 with SMTP id m11-20020a1709026bcb00b001ae5fb04256mr2802689plt.57.1684515420128; Fri, 19 May 2023 09:57:00 -0700 (PDT) Received: from ?IPV6:2601:681:8d00:265::f0a? ([2601:681:8d00:265::f0a]) by smtp.gmail.com with ESMTPSA id n4-20020a170903110400b0019ef86c2574sm3652462plh.270.2023.05.19.09.56.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 May 2023 09:56:59 -0700 (PDT) Message-ID: <62638b5e-d9a5-0ede-0642-ea363d23d055@gmail.com> Date: Fri, 19 May 2023 10:56:58 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [PATCH] MIPS: don't expand large block move Content-Language: en-US To: YunQiang Su , gcc-patches@gcc.gnu.org Cc: macro@orcam.me.uk, jiaxun.yang@flygoat.com, syq@debian.org, richard.sandiford@arm.com References: <20230519061152.3154332-1-yunqiang.su@cipunited.com> From: Jeff Law In-Reply-To: <20230519061152.3154332-1-yunqiang.su@cipunited.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-9.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,KAM_SHORT,NICE_REPLY_A,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 List-Id: On 5/19/23 00:11, YunQiang Su wrote: > On platform with LWL/LWR, mips_block_move_loop is always used, > which expand __buildin_memcpy/strcpy to a loop of lwl/lwr/swl/swl etc. > > For short (normally <=64), it has better performance, > but when the src/dest are long, use memcpy/strcpy lib call may have > better performance. > > At the same time, lib call may be optimized with SIMD, so, > on the platform with SIMD, lib call may have much better performace. > > gcc/ChangeLog: > * config/mips/mips.cc (mips_expand_block_move): don't expand > if length>=64. > > gcc/testsuite/ChangeLog: > * gcc.target/mips/expand-block-move-large.c: New test. > --- > gcc/config/mips/mips.cc | 6 ++++++ > .../gcc.target/mips/expand-block-move-large.c | 17 +++++++++++++++++ > 2 files changed, 23 insertions(+) > create mode 100644 gcc/testsuite/gcc.target/mips/expand-block-move-large.c > > diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc > index ca491b981a3..00f26d5e923 100644 > --- a/gcc/config/mips/mips.cc > +++ b/gcc/config/mips/mips.cc > @@ -8313,6 +8313,12 @@ mips_expand_block_move (rtx dest, rtx src, rtx length) > } > else if (optimize) > { > + /* When the length is big enough, the lib call has better performace > + than load/store insns. > + In most platform, the value is about 64-128. > + And in fact lib call may be optimized with SIMD */ > + if (INTVAL(length) >= 64) > + return false; Just a formatting nit. Space between INTVAL and the open paren for its argument list. OK with that change. jeff