From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) by sourceware.org (Postfix) with ESMTPS id 18D14382EA27 for ; Fri, 30 Jun 2023 22:35:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 18D14382EA27 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-oi1-x229.google.com with SMTP id 5614622812f47-3a36b309524so1832190b6e.3 for ; Fri, 30 Jun 2023 15:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688164505; x=1690756505; 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=wrH/aokfe46vtshjk2gwkEI1dK6Ia3f/r+YN8Kc706E=; b=o+UJTD40yXYtgtbhKTjSt6WKxBI04dXPEDmg+DyBZLpjGKtAMYiIRVm8ghfGj1FMMI OAWjL+XPRdmy08MMROUXdVj7Wc26K6ahnqPE9ombPzU8hq022bQWIJZPxLHDXe0mMP4s WwcFHz/pOcUcjggzAwJlAtEgrkBEaczi7EGACENivztDg/k9r50yPknRs2y+kLAYVv/z /P1KbpUZiNy7nD9CMqIkaDx+nq2p9uwfnrs0komW72W/I+DrrsQtt/4Pv9iiX6ttHMXC Jjh/XnLwPI0z3358Pcjwe6ItbeQ+v0ym2TRwQK98Pmju5ScshOjVCsBiqGyNLVxbO9OH pUQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688164505; x=1690756505; 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=wrH/aokfe46vtshjk2gwkEI1dK6Ia3f/r+YN8Kc706E=; b=fD9RMTyKyVvaaZ9iSHJvc/pamV21BmMsnB5fStxO1Y7m5yi1VIzC1yPpW6QWnBX9aa QPdB6xQESzDFVCUmnN4DkwXMduBW/u0P3WIXFAAxDwv9QrqrEs5HiNAzMcC3jtfq51bf bOWDAzLTVqOMdgK8sEnfap/JtDkND62ONXLNqtILGzVZ2Lzj+HhKm+yEydfdURGp6Zs5 0fuYVwYEZ4D0VG3Bo8E6UWg9p5o5TPLO6GrfVHcl8xfOB/Dx03MH1qkauCPWo5KEF+GJ doG+ez31i2JVoimNRREZOfnQn21JqAsDL0aFF7a60j4+B/WPAAmPMT9hkUaxEQ5rGvWL xS8A== X-Gm-Message-State: AC+VfDwTCsO1CFCjcIte9KvpSoqaKCVdun/Cp13tTbasAqO2RYB6w+Ri qWugcydCn2w7V1jt9uB1vH4= X-Google-Smtp-Source: ACHHUZ42pbXPksfWlKk8IFV+btuxl0r9Q1NCbBq9BP3qVUWmRftnSeTS8XrnstrHFMpoFXPWY1HQjw== X-Received: by 2002:a05:6808:20a7:b0:3a0:50bf:64fc with SMTP id s39-20020a05680820a700b003a050bf64fcmr5014153oiw.27.1688164505192; Fri, 30 Jun 2023 15:35:05 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id u22-20020aa78496000000b00640f1e4a811sm8793737pfn.22.2023.06.30.15.35.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Jun 2023 15:35:04 -0700 (PDT) Message-ID: <11e4d710-cc52-748a-7ab2-ff489c2a02aa@gmail.com> Date: Fri, 30 Jun 2023 16:35:02 -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] RISC-V: Support vfwmul.vv combine lowering Content-Language: en-US To: Robin Dapp , =?UTF-8?B?6ZKf5bGF5ZOy?= , gcc-patches Cc: "kito.cheng" , "kito.cheng" , palmer , palmer References: <20230628041512.188243-1-juzhe.zhong@rivai.ai> <70EE22A0D10CD0D8+2023062906005450585022@rivai.ai> <62be1be8-280f-2989-6a31-32c87dcbadcd@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 6/30/23 04:14, Robin Dapp wrote: >> The explicit conversions I see are because we need the output of the >> conversion in multiple vfmul instructions. That won't be helped by >> the patch you've proposed. > > FWIW on my local branch and the patch applied I see that the vfwmuls > are being generated (all of the vfmuls are replaced). > >> It'll need to be a define_insn_and_split as its a 3->3 splitter. The >> split will emit the two extensions and the widening multiply as 3 >> distinct insns. > > I tried this and while it worked for the first vfwmul the subsequent > ones are not being combined/optimized. Now I'm not a combine expert > at all but it looks as if the source float_extends are being deleted > > deferring deletion of insn with uid = 39. > deferring deletion of insn with uid = 37. > > with that pattern successfully matched, while they are only "rescanned" > with the synthetic "single widen" one. Them being deleted (or rather > absorbed by the vfwmul) no further combination is possible (until after > split?) > > This seems to be a fundamental difference between the two approaches. > Maybe the "double widen" pattern can be adjusted to also handle this > or I did something wrong when writing the splitter? > > With the "single widen" pattern, however, it works more or less > naturally therefore I'd still suggest going for it. I'd hoped to have time to revisit all of this today, but I'm quickly running out of time. There has to be some kind of mismatch between the patch or testcase or what we're looking at to judge success. Monday and Tuesday are holidays in the US. Naturally that means the rest of my work week is going to be busier than normal. I don't want to hold things up unnecessarily. While I really don't see the need to have the bridge pattern, I'm still willing to believe that I've missed something, which is why I wanted to dive into it myself. For example, we have heuristics to avoid trying too many 4->n combine patterns and we might be tripping over that or who knows what. So my suggestion is that if both of you are getting the desired code, then Robin handle the review side of the two patches that introduce the helper patterns. Jeff