From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id DDA553858D20 for ; Mon, 12 Jun 2023 23:34:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DDA553858D20 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-pl1-x630.google.com with SMTP id d9443c01a7336-1b3db8f3d07so7637245ad.2 for ; Mon, 12 Jun 2023 16:34:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686612849; x=1689204849; 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=6WPdtAATUOJoqFU3niiaCz/xAtIUbbiYu7pZU2PuAgk=; b=B+dgoWMNppN6bXwpyhUhvhuaFpmJ5zFOmbRK5wLZZDE0iWIa40b/RO5q8Se9jojzcd 72lcNHcbroMOAH8SbDgE38NSrGBAVtPTUQDiMnIdIidSWAKvJOWiD9DcpxkWf8r4yEY/ FBqxHb89LvZtZQIIcg2ZHBiDFnrok+CIqcnMqS+Bv07VvhEBkDjnQFACBUKOu8hymIAa po6pmDVO6qJML+jFHbJtonv64V7K36rqGkl10thTRZxMXfoMoYhAj9sNvb0pOiHJiYxy AU+F0A+Dw1CXmutn53KLthlggfN7M4RH2SGf5Vy5ntdo3ltVvRQOlyMd9xwmXTgH6XWx /9ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686612849; x=1689204849; 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=6WPdtAATUOJoqFU3niiaCz/xAtIUbbiYu7pZU2PuAgk=; b=CMzNzDo6be1xIlFLTReG75MXlIg+2DjWrbrVqrlh/ZMlC1kVm+mhL6V25iQYOczAlO KnSNYL0IYQHprwpEHl+AnF1P/qPy9ZovEAyzWgpFmuepudvlGa0gXqI2CiETVR9ail8G zfIWug8UHv+xw12SCfjyy24ugUIHPbpdX4Y50LIOwzM7no6S/JP9kr7JWFRgjmjS4BzL 6u/06sOea3bx5gGWq1jvvpxEEjjQmuTL6OicQ7k99ZYT2Y4STunKNwnxaJQtXPzAJ8Yf i2+GI2/d/CGdmqPt/sUnBnennxFPKM56kaOJwtV/8T8KP9AzNC6GtN+FxnG+t79rZl22 Thiw== X-Gm-Message-State: AC+VfDxnmYsj7xMY6ki/8J+lKi4BCw8lLuKVaPBSG1pTdCMKfgMCFqOG mTU+54C9GqCYxq1Tyn2pntY= X-Google-Smtp-Source: ACHHUZ6diNFRak0HK8JVP98dBpzYJcaQY4jVDg4bosrLvIzLfw5ybOsKIxTCTdYsYXF95ALaSc1h5w== X-Received: by 2002:a17:903:120b:b0:1b0:2658:daf7 with SMTP id l11-20020a170903120b00b001b02658daf7mr9525858plh.36.1686612848770; Mon, 12 Jun 2023 16:34:08 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id x21-20020a17090300d500b001aafa2e212esm8808800plc.52.2023.06.12.16.34.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jun 2023 16:34:08 -0700 (PDT) Message-ID: Date: Mon, 12 Jun 2023 17:34:06 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [PATCH] RISC-V: Basic VLS code gen for RISC-V Content-Language: en-US To: "juzhe.zhong" , Kito Cheng Cc: Richard Biener , Robin Dapp , "Kito.cheng" , gcc-patches , palmer , "pan2.li" References: <20230530060621.31449-1-kito.cheng@sifive.com> <87B2E2DEA59DF7D1+20230530154530505119343@rivai.ai> <5873dbb5-ef8f-6411-1841-d849030554e3@gmail.com> <8AF15FA3F4884D3C+20230530174423101539359@rivai.ai> 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.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: On 5/30/23 17:37, juzhe.zhong wrote: > Oh. I forgot we need vl/vtype regnum dependency. It seems extending vla > pattern with vls mode is unavoidable. So.... I think we can > define_insn_and _spit and split intructions after RA so that we can get > benefits from general rtl code patterns. So you're suggesting to represent them in the relatively simple VLS form until some split pass (split1?) then lower the VLS form into the VLA from? Isn't that option #2 from Kito's proposal? Essentially at split1 we convert the VLS into VLA and it stays VLA from that point through codegen. I know Kito said it "might be weird and not natural", but in my mind I can easily see the version step as a lowering which very much matches what we often are trying to do with define_insn_and_split. The downside is we end up duplicating a ton of patterns. I think one of Kito's proposals was to add an iterator to the existing sets so that the VLA patterns match. Presumably we'd then key a lowering step based on the mode? Where do we stand on this now? Waiting on Kito to resubmit a VLS->VLA lowering via define_insn_and_split or do we think Kito's approach is viable? Is this blocking any work? jeff