From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by sourceware.org (Postfix) with ESMTPS id CC4D93858404 for ; Tue, 26 Sep 2023 15:15:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CC4D93858404 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-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-27734d76e1bso3749704a91.2 for ; Tue, 26 Sep 2023 08:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695741330; x=1696346130; darn=gcc.gnu.org; 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=lYdbGD5Q6swEtAcHQNBMSEcxoSUG09pscqOuU3GPUQw=; b=VhXLI7VxULhBtt2tOqduDnvT9d3H7PSYHc00h/2YmizsOeMvC7ejxjxXa+ua4uKgQ5 DPstUywV5ihMj8Ti84AaYYSask1gSvWmW4I3xySF+OYfKoi3QEXglzAltcn5kWlnjXmz JYPbgOjkk2633QnoTxAI856vhYnmitOBHfsWmDazJGcPDlOUlL5hs0CD3LfGRbWqCaFU FfnL3Xa2KUtkvU7mc5rhSBIvKkf9AgoNH45ZfN1QD4nuvcXvxK+aGqrDZhcEsxcDZmF6 q4IdeXqiDRsjML2O29kExxXZ4PT1/1FlPWxuEzn3vkEYSOcAZsoOCxnwZ/lt3g1yxWMp 1wig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695741330; x=1696346130; 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=lYdbGD5Q6swEtAcHQNBMSEcxoSUG09pscqOuU3GPUQw=; b=EJsXEZWASbCA3X32d5dvba6TfK171lg71fgYBgsSI2Rv7mLZqBYVBEqFfqoRx7qda/ bJqqEnASWaAjPGOLultYWqKhbfRuoLxFgyNUiobjYu2ZrthAf0BHBa3ZKYoyhErMiZ7K B1UG2mSIYRdUvSX/+nb8O74J0cOIKLjs4LA04tRN3taEh54aCv7guzk/aGNQYDRNPz2b 9jYhc37zbmh2/EqS41uV0mLzjm+9mKGgbYe2qzDZkktqx5MAnMPySbNG1Rts0qIKYhCF AG4eeiSUaSLCeJ0mPrdvOAy+3iS+lPFq5YAW3bK3QLryu/w5Ui3uUbcGz9kK1neGNvoC a52A== X-Gm-Message-State: AOJu0YzenaR88b2+7/1XSazTILrsUijuoTOELsq3BcdY6GyF+6AhRwCT Zyb5Ip7NZ9idfWUTvu1nntY= X-Google-Smtp-Source: AGHT+IFLS2wS9m7ckhAiMW07HbC8Jj0Bwc0qJFEYv5RDSLL7tRjcXzPYYrNhD6Qk9BQiiAX/RD5auw== X-Received: by 2002:a17:90b:2386:b0:267:faba:705 with SMTP id mr6-20020a17090b238600b00267faba0705mr5994879pjb.10.1695741329576; Tue, 26 Sep 2023 08:15:29 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id sf9-20020a17090b51c900b002609cadc56esm9895982pjb.11.2023.09.26.08.15.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 Sep 2023 08:15:28 -0700 (PDT) Message-ID: <2f2b555e-adb4-4cad-bbb2-936928c78de4@gmail.com> Date: Tue, 26 Sep 2023 09:15:27 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [Committed] RISC-V: Fix mem-to-mem VLS move pattern[PR111566] Content-Language: en-US To: =?UTF-8?B?6ZKf5bGF5ZOy?= , gcc-patches Cc: "kito.cheng" , "kito.cheng" , "rdapp.gcc" References: <20230926131532.1935361-1-juzhe.zhong@rivai.ai> <45a872a8-5370-4755-99b4-2cad7453db81@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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 9/26/23 08:51, 钟居哲 wrote: > Thanks Jeff. > > Address comments: > [PATCH V2] RISC-V: Fix mem-to-mem VLS move pattern[PR111566] (gnu.org) > > > Actually, we only allow mem-to-mem move for VLS modes size <= > MAX_BITS_PER_WORD. > Since we want to optimize this case: > > - typedef int8_t v2qi __attribute__ ((vector_size (2))); > - v2qi v = *(v2qi*)in; > - *(v2qi*)out = v; > > using scalar load/store. That should be do-able without resorting to a pattern that allowed mem->mem moves. THe thing you have to be careful about is in the effort to optimize this case, you can end up confusing the register allocator into making poor choices elsewhere. ie, once you expose a small vector move as implementable in GPRs you run the very real risk of pessimizing other code. But even with that caveat, the better way to go here is to disallow the mem->mem case. jeff