From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) by sourceware.org (Postfix) with ESMTPS id 8AF093858CDA for ; Fri, 28 Jul 2023 15:03:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8AF093858CDA 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-pf1-x42d.google.com with SMTP id d2e1a72fcca58-686ea67195dso1691801b3a.2 for ; Fri, 28 Jul 2023 08:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690556603; x=1691161403; 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=4IztrsS+e8etAg8XLKXpWrVIuC/TD4qZwOCy+UZ2ikg=; b=UL2DnsoBvpGoezCadE1nkRhTH/56LICvb/4NE5WDsppnwlWs090WnoWWNCtt0iLq8c sP7TMixwMgRg2EQB5Rj3Wzy1FuHUZ2vW9fXQ8pKaUs0V06TeDBjN3aw00D5bbwTrRBR4 kJMXBmdBWxkTSYOse0kME8b7aNw4rDdlzOQF1AJ8EktFRkzq3hQBwUUgsghbNbKsTw15 k4nI7yaa+aatsD+xZhsud7i3c2tiUTkw0DJLVQw2weQy30eCWSdeur9ZMCT5I4WPUAXm IR36pJaz4+W+oYaIaVLm2+7Pz1ZSfE/xJ7SUTCxfIsoz9P4gkD9JojjT+3EV0V/AhYCk 6hMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690556603; x=1691161403; 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=4IztrsS+e8etAg8XLKXpWrVIuC/TD4qZwOCy+UZ2ikg=; b=kMI3cwq3RaKvV53ypIquxU7UBWFByacuFxt23nSnRA9Z8Bj/9sHtnnsz5fp0YeSqGc TyMbTzEm1m+5zL0Yk9djlRFeLDDndL+AQ5zeIasUmx0j1bf0Cq4CyuUxguBRjrB+IWw2 PIt2ZlAdz6Ap0FN19eNWck/uZApsOYhJ6g4/na9Dlr85i03VEdNOhjdVkQrV7JTxCRBP fQxekcOqJ5Bp77JvBo0irVEJNmw/oW2D3qfBt3AEzmjbvbXKdz7pHbZggD7nyLOmrMaN tl5MXLyhL3n4ld9DNS1a6dFuLh1tMGAvkkIVJ8K8ttGLZ0kVStZ2heZi/XhAKGZDAmVX lxrQ== X-Gm-Message-State: ABy/qLYZMOM7mendkPW3YvP7OFc5s16+JIoB8eE4PVAeHI1j4Q0+on60 0aiTvF+L7CxTo2nPH155N54= X-Google-Smtp-Source: APBJJlFnkBJcpPFXh0xJeFEzmeQaG8vWNiJCrCSSto2UJQ+vQSJVn75pyfjDAfuPcPJRzghiCSKaVw== X-Received: by 2002:a05:6a20:a11b:b0:132:7d4a:34b5 with SMTP id q27-20020a056a20a11b00b001327d4a34b5mr2237226pzk.37.1690556602393; Fri, 28 Jul 2023 08:03:22 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id u3-20020a62ed03000000b00682a839d0aesm3321579pfh.112.2023.07.28.08.03.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Jul 2023 08:03:21 -0700 (PDT) Message-ID: <5eab1189-6105-1471-6039-8b40e461ffc6@gmail.com> Date: Fri, 28 Jul 2023 09:03:20 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH 0/5] Recognize Zicond extension Content-Language: en-US To: Xiao Zeng , gcc-patches Cc: research_trasio , "kito.cheng" , zhengyu , eri-sw-toolchain References: <20230719101156.21771-1-zengxiao@eswincomputing.com> <2023072716434903717718@eswincomputing.com> <86dc9255-3d7b-54fc-1c3c-35373218c5f0@gmail.com> <202307281434423583808@eswincomputing.com> From: Jeff Law In-Reply-To: <202307281434423583808@eswincomputing.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.3 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,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 7/28/23 00:34, Xiao Zeng wrote: >>> >>> Does that work for you? >> I'm going to look at 3/5 today pretty closely.  Exposing zicond to >> movcc is something we had implemented inside Ventana and I want to >> compare/contrast your work with ours. > > What a coincidence! Zicond is a direct descendant of xventanacondops. The only notable difference is in their encodings. > >> >> What I like about yours is it keeps all the logic in riscv.cc rather >> than scattering it across riscv.cc and riscv.md. > > Yes, when I use enough test cases, I cannot find a concise way to optimize > all test cases. When I enumerated all possible cases in the movcc > function of the RISC-V backend, I found a method that satisfied me, which > is the method in patch [3/5]. I got pulled away to another task yesterday, so didn't get as far as I wanted. The biggest inight from yesterday was determining that some of the cases you're handling in riscv_expand_conditional_move were things we were doing inside ifcvt.cc. The difference is likely because the initial work on zicond here was primarily driven by changes to ifcvt. It was only after evaluating that initial implementation that we started to the effort to use zicond at RTL expansion time. I could make a case for either approach, but the more I ponder them the more I'm inclined to go with something like yours. We want to capture the cases implementable as a conditional move as early as possible in the RTL pipeline rather than relying on ifcvt to catch it later. It also avoids polluting ifcvt with transformations that are only likely needed on risc-v. >> > > If it's just for the Zicond instruction set, is it necessary to make judgments > outside of eq/ne? After all, it does not support comparison actions other > than eq/ne. Of course, it is also possible to use a special technique to use > Zicond in non eq/ne comparisons. It's not necessary, but it's definitely helpful to cover the other conditions. In fact, we can even cover a variety of fp conditions by utilizing the sCC type insns. So what I'm looking at for patch #3 is to split out the costing bits into its own patch which can go forward immediately. THen continue evaluating the best way to handle unifying the expander/canonicalization code. Your testcases in patch #3 are particularly helpful to make sure we're not missing cases. Jeff