From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x36.google.com (mail-oa1-x36.google.com [IPv6:2001:4860:4864:20::36]) by sourceware.org (Postfix) with ESMTPS id BDB3F384F037 for ; Mon, 14 Nov 2022 19:10:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BDB3F384F037 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-oa1-x36.google.com with SMTP id 586e51a60fabf-13ba86b5ac0so13598416fac.1 for ; Mon, 14 Nov 2022 11:10:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; 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=Z1fSxrSO3vmGpdGmxWco6r620As7gAQCkORVOXCYaas=; b=ikt0R4/Po8ZUxrEEvnUuaIdFzO5HlNAPQ8ENoW63LPsDbAhLmxPdVTypd0JjbSnAvp fjgPtySSKC9DIX7nV/5t5+38xckZx16pI62CVErcrUk+/74iUQNGXclWG9qNNCXZmewW 0I6bclonkWFLWUlOX6ZLEGXqcfD8PF4t9VXit+aczwIJ4v1ip2pOVugq5ROhIZraQYqb YBBNzIN0XryNnBAyIYqhXAtb6Zqhv6F4vmLYMEVmz2vEo7SvJ8FOBZZnefTIeUWFStGz WbCiNJvNXUMWqcVmr7az8eRLyEm4zX7cp1JnoqCBXEXDV9mtd4Qt8sAZs0ET7P+i/g/O UOfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=Z1fSxrSO3vmGpdGmxWco6r620As7gAQCkORVOXCYaas=; b=NPYzo5XEm73us8HnuwVY9gcxvfELkm/T/a/E1n7t+aK8T9WmMVRO9BkXSa0LAyXlV0 zhNo4FYaNTm7vU66YF+UrB+dTO+XyphSc8CMGe14Wcb5ih7tR5pr8t7QBuYgo/JMAqji FerJJQ5Az61uDzMEqSAw12HkZ9ypoCuW3Ao5pVLQdingyRto9Pmj4CwnV1q4dGC/Rpdh S2Oj6SQprgChsj+ip6ZX02tWvViJ9gUxK7zl7dvSIiBSFdozvbDmGfZlG1ZNBmNP/ctq Me/w46HHeMnF3pa+41OtxRRkYYXsT5epY7g2kqhNiT876dwE1wKW/Q0lgpRkFD3l/CYd LAnw== X-Gm-Message-State: ANoB5pk2lla3DrChB2m4mtBfZNEUVid4rz13QA1yf1p5nYNFgseRnpT7 HVLX8UrAVLpmygbi7Pe/U2E= X-Google-Smtp-Source: AA0mqf5TTXvwkNsNP4kg/1TdyZGA0JREqjAolI93t+1mp+k7QI0ZNO25nuwwLch9piwW4UWYfDi78A== X-Received: by 2002:a05:6870:9a10:b0:12d:23af:22bd with SMTP id fo16-20020a0568709a1000b0012d23af22bdmr7376921oab.256.1668453022976; Mon, 14 Nov 2022 11:10:22 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id n8-20020a0568301e8800b00660d9afc216sm4425511otr.17.2022.11.14.11.10.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Nov 2022 11:10:22 -0800 (PST) Message-ID: <8ccc2d99-1e8b-5a0c-e1e0-f3936aa0d31c@gmail.com> Date: Mon, 14 Nov 2022 12:10:20 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH v2 2/2] RISC-V: Add instruction fusion (for ventana-vt1) Content-Language: en-US To: Philipp Tomsich Cc: gcc-patches@gcc.gnu.org, Palmer Dabbelt , Vineet Gupta , Jeff Law , Kito Cheng , Christoph Muellner References: <20221113204824.4062042-1-philipp.tomsich@vrull.eu> <20221113204824.4062042-3-philipp.tomsich@vrull.eu> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.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 11/14/22 11:55, Philipp Tomsich wrote: > On Mon, 14 Nov 2022 at 17:06, Jeff Law wrote: >> >> On 11/13/22 13:48, Philipp Tomsich wrote: >>> The Ventana VT1 core supports quad-issue and instruction fusion. >>> This implemented TARGET_SCHED_MACRO_FUSION_P to keep fusible sequences >>> together and adds idiom matcheing for the supported fusion cases. >>> >>> gcc/ChangeLog: >>> >>> * config/riscv/riscv.cc (enum riscv_fusion_pairs): Add symbolic >>> constants to identify supported fusion patterns. >>> (struct riscv_tune_param): Add fusible_op field. >>> (riscv_macro_fusion_p): Implement. >>> (riscv_fusion_enabled_p): Implement. >>> (riscv_macro_fusion_pair_p): Implement and recoginze fusible >>> idioms for Ventana VT1. >>> (TARGET_SCHED_MACRO_FUSION_P): Point to riscv_macro_fusion_p. >>> (TARGET_SCHED_MACRO_FUSION_PAIR_P): Point to riscv_macro_fusion_pair_p. >> You know the fusion rules for VT1 better than I... I'm happy to largely >> defer to you on this. >> >> I do wonder if going forward hand matching RTL like this is going to be >> an unmaintainable mess and whether or not we would be better served >> using insn attributes to describe instruction fusion. > I had thought about that, too. > In the end our team decided to stay away from it for the time being: > fusion frequently needs to look at second-level properties and whether > the first instruction's output register is overwritten by the second > instruction. So we kept with the same stereotype of idiom-matching > that is also used for AArch64 today. Yea, we're still going to have to grub around to get the operands.  But we'd know the overall form of the insn and the types of its operands was right.  But it's still going to be clunky either way.  My worry with the attribute approach is we'll end up with a horrible mess of attributes due to multiple fusion implementations and that we'll need to split alternatives so that we can tag them more precisely, etc. It feels like we almost need a DSL to specify this stuff, much like we have for scheduling models. Jeff