From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) by sourceware.org (Postfix) with ESMTPS id B0CF63858D28 for ; Mon, 28 Aug 2023 21:34:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B0CF63858D28 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-pg1-x536.google.com with SMTP id 41be03b00d2f7-5654051b27fso2123191a12.0 for ; Mon, 28 Aug 2023 14:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693258486; x=1693863286; 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=G6GPuOB538sL9vkjFFAuh00OEggd9t7nW2iE1TvknT8=; b=DS1pSoGnWb7CPFCHQhQVZ1twvqH5YY1Cvuuh8tlRE7QcGg2F07vXxgo1o/4NmsC553 AotoUYfygSrQHzbafL3xJZn0TQRkwhw5lQvGLQRFAInHMSj6cBIeKYfjRqNkbO+iHL3D QB/32D1dWXVrJrmUfLQ/4yxakX+8IpKYSIjLfpELAampnLn4Y2edqrtnVvm59Gd6B9nY dhmiSBikZK6h1GQQQWT8oX99/pS/CWMAesw7+P57A8vv+KWWgZC+GkpbFBAD9eoWPJX0 AAFip53Y9G/ouA+U46WOToDH/jkyUtPYK8IBU8Th+Md52ikpZNGfWj8ga5ISLXJNv8XF Tlrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693258486; x=1693863286; 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=G6GPuOB538sL9vkjFFAuh00OEggd9t7nW2iE1TvknT8=; b=SDwnv4BoEqqkL8d54aJUC7qSO7JhOLOrWNhWXShcjphRw0xoR7MyCqXepnU+y3omHE ylDEO06c1j2Syre8x7VhOR5ObhTVY336fhe0NoD/Ha8K9qUCl+eSruq4GvIZ0afdeWiX QhabTJ01Jc/Doe/iJx7Ix89SmhEguaa1TL2WWLCP8uQVzhRJNxqoBvqDh2TozAS6QHUF brofJZd+VCPwgWG/l9ZDxjzM9qH1eS2vi51QA+vgZiMav9FFOFVv6NVshvJcXdNwl9/K lB6K8uzDoUfW3+EB+z3jnNUm//w6KIYJCJ6DwXerfSP2B/To3qH0oiO+DVlktYbY/4lP ogiw== X-Gm-Message-State: AOJu0Yzt78bMzOYJEIKL+FkKkXrMBAVrXGZO1aZL5n3sO0f8IvnzZEg3 eXDVPjW62OtauYpPHcMAL0w= X-Google-Smtp-Source: AGHT+IG4hC61ny4t0KMdeTmT9S8emQkDnikA01ZQfj+AnfhK+fDvJCXnmcmrc8UbM/5YtpMemMoKjA== X-Received: by 2002:a17:90a:fb89:b0:26b:534e:234 with SMTP id cp9-20020a17090afb8900b0026b534e0234mr22963839pjb.35.1693258485635; Mon, 28 Aug 2023 14:34:45 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id f6-20020a17090ab94600b0025bdc3454c6sm9466885pjw.8.2023.08.28.14.34.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Aug 2023 14:34:45 -0700 (PDT) Message-ID: Date: Mon, 28 Aug 2023 15:34:43 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH] RISC-V: Fix error combine of pred_mov pattern Content-Language: en-US To: Lehua Ding , gcc-patches Cc: "juzhe.zhong" , "rdapp.gcc" , "kito.cheng" , palmer References: <680c9180-6db6-0dd7-d93a-aa12cdfbbbac@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=-3.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,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 8/11/23 10:30, Lehua Ding wrote: > > But combine doesn't run at -O0.  So something is inconsistent.  I > > certainly believe we need to avoid the mem->mem case, but that's > > independent of combine and affects all optimization levels. > > This is an new bug when running all tests after fixing the combine bug. OK. I must have misunderstood. Thanks for clarifying. > > > I think we can simplify to just > > !(MEM_P (operands[0]) && MEM_P (operands[1]) > > > I would have expected those to be handled by the constraints rather than > > the pattern's condition. > > Yeh, the condition of the V2 becomes much simpler after split. That was the hope. It is worth noting that for simple moves eg movsi, movdi, movsf, movdf, etc there is a requirement that a single insn support all the valid combinations. But I don't think we've ever had that requirement for vector modes and the situations where it's important are much less likely to trigger for vector moves. Even more so given how the cond_mov patterns are implemented for RISC-V. Jeff