From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) by sourceware.org (Postfix) with ESMTPS id ABDC8385DC05 for ; Fri, 30 Jun 2023 10:14:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ABDC8385DC05 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-ej1-x62e.google.com with SMTP id a640c23a62f3a-9924ac01f98so210191166b.1 for ; Fri, 30 Jun 2023 03:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688120063; x=1690712063; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=7yEknbihaHBCPVM+v8aCtqIivHonELvwu6xNFMae/ic=; b=mhdF8qs1+/uxrBO7Fxjz5DqV7CLtjm3EpE7EazCjs783zgy+yMDp0ruX/59ogZyySk HzQqPQFCgBUIi8XiV7RDexzvRB6ZOCb7qaQZSTxx++mMcSTZtMSCNSkMwlqyvvRuhNKk DdH0O1/Yg2sf/19pNPSgYsKshi6dYe0wwTVV9ud0Yz59lAFqBuP854ZDTr3h2edF2LEj SbsMYl2vqUD0/m8vNzdzer6yDMHc3yLHpLj4zlkL56v6YJlTF9D1mrjrpngnzClrFf5x 6TSr6c+SJ7i7qVynMneFQt+J1l4pkQpBS7DXl5ICM7q3G/bDYDDsJkmBgazpqKaiLSjC UqUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688120063; x=1690712063; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7yEknbihaHBCPVM+v8aCtqIivHonELvwu6xNFMae/ic=; b=SKpuE8HTLRauu/DaJu2qsN41h0tBP192u+DbInn1Rc+n67/C8p1VViblLX2bk4JVV3 n6KAOqKCeJ2ikFK48UArtoQRkBUwGtt3tw1xmAcAoGA9xhWk37h2LOWQ6MWMAZx8jIEA gNjQ0zHxHIPtlSgoY8QhT9B2apFk6NPcw6CNetWMXCNGZYIEikkBZByMsTqdemVyBI+Q yP5QAuRefTqqliVnwyVV/hrAmXPQYS9DIqy7Va99zYRkDO2PYn4AstsZ/B2pSCRWGGHv xWtGxieg/Fyo34aYN2k5yuz44FjNlSPU00/phOI241tmTs0pbZwV1NUhwOQ9LOcodjml 2D3A== X-Gm-Message-State: ABy/qLb+QERWP81feK1O6ry+b4UGjg+sPspdE2Y6FtKgN23d41tVs4VP W/P0V+Wy3KxxLOSaIPP/51M= X-Google-Smtp-Source: APBJJlE2Nth/oQDH2CXZKlZNv3z7YBlEnRXU+gjia4rZzUANxcIgBylgh/zRj2FUioZfZe57RruSZA== X-Received: by 2002:a17:906:1319:b0:98c:8694:9525 with SMTP id w25-20020a170906131900b0098c86949525mr1687017ejb.4.1688120063181; Fri, 30 Jun 2023 03:14:23 -0700 (PDT) Received: from [192.168.1.23] (ip-046-005-130-086.um12.pools.vodafone-ip.de. [46.5.130.86]) by smtp.gmail.com with ESMTPSA id le11-20020a170907170b00b009927d4d7a6dsm2726423ejc.192.2023.06.30.03.14.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Jun 2023 03:14:22 -0700 (PDT) Message-ID: Date: Fri, 30 Jun 2023 12:14:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Cc: rdapp.gcc@gmail.com, "kito.cheng" , "kito.cheng" , palmer , palmer Subject: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering Content-Language: en-US To: Jeff Law , =?UTF-8?B?6ZKf5bGF5ZOy?= , gcc-patches References: <20230628041512.188243-1-juzhe.zhong@rivai.ai> <70EE22A0D10CD0D8+2023062906005450585022@rivai.ai> <62be1be8-280f-2989-6a31-32c87dcbadcd@gmail.com> From: Robin Dapp In-Reply-To: <62be1be8-280f-2989-6a31-32c87dcbadcd@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.4 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: > 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. Regards Robin