From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id BF1E43836E8E for ; Tue, 30 May 2023 07:27:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BF1E43836E8E 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-x630.google.com with SMTP id a640c23a62f3a-96f6a9131fdso616237066b.1 for ; Tue, 30 May 2023 00:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685431622; x=1688023622; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:cc:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=n6Bq0p5mZ9azxJZ7ai0OqrGpGtKijbRgNIvb0BlvxOc=; b=Zs2ggj88c13RDW2VK+2CvwxCgoKreNjhLSRB7QLpUrk10aTdgPW0xhxGZvk7ixhInc +kFXE8cispNWIlrEOX73Hu1O2FX72BX8KTZByGsYlM6sYI69vvRuq20ZxcSNODwNGvIZ 5lt8BO/PETj46bvYfd0aD6Wt78lDt4NPwK9FjG8YqH0Tgd6sFR6ebSnhbxgADIS2txsL dbADzSKI/pS1FlKzvtpmJGb7ToQY6ETHtf+flk2FqEIUolowLMycxHBtTpad6YFnsTus h79BSpGboao4bfoJfS38tMMo8gVQKIc+StTkBejuHTCJgdHj6+PqfbYtpHegJySSRcmk OiZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685431622; x=1688023622; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:cc:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=n6Bq0p5mZ9azxJZ7ai0OqrGpGtKijbRgNIvb0BlvxOc=; b=bktwbyDIIjcKXsz1HU3u/e06cSWCSn8eBTMoB9uyoLMN+SUw+t79GhlWThjwhhVVP+ bh6HoOw3IWlk/xSNXJMDWJAZwx6nJDu4u4JOW68R7yjSDiNUPc86gEjdSiHfko851Qe7 ScPpdfDZOyRNC0IWcvj+va+zXkaNpsmqn1UyjjrXjT0SwYJI4fj0mvOFvt17b5YT6vsP bAozrZg8CZceOik/uDet8RuZdbsZ9Df6CD8ZWeG1tuaoP3SWMVNOYqNZAkiP6lAcHKnc wUBezBYXAsqC3yPmOuQ+KwHYsUJOGR/wTCPqoqS3pQ/s338EEkOQrJa0aVXayvusJljU Sy3A== X-Gm-Message-State: AC+VfDweB7f6bnk6aMe9+2xnr7fIvY5plNkSuQ9hh/OXNmxV11Fb4YKj KAhcPIJGdBQBmw6ggb7dVTg1dnbu2cY= X-Google-Smtp-Source: ACHHUZ7vX0z/pcjQ59nAuaNjIwLzVLQPaL/sL9JF+lG2FoAA5N5jEZFNnKBwJ59O4/hj/MeYLyb8jg== X-Received: by 2002:a17:907:8a22:b0:969:7739:2eb7 with SMTP id sc34-20020a1709078a2200b0096977392eb7mr1774903ejc.4.1685431622168; Tue, 30 May 2023 00:27:02 -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 bh1-20020a170906a0c100b0094f44bdf7acsm6945450ejb.57.2023.05.30.00.27.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 May 2023 00:27:01 -0700 (PDT) Message-ID: Date: Tue, 30 May 2023 09:27:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Cc: rdapp.gcc@gmail.com Subject: Re: [PATCH] RISC-V: Basic VLS code gen for RISC-V To: Kito Cheng , gcc-patches@gcc.gnu.org, palmer@dabbelt.com, kito.cheng@gmail.com, juzhe.zhong@rivai.ai, jeffreyalaw@gmail.com, pan2.li@intel.com References: <20230530060621.31449-1-kito.cheng@sifive.com> Content-Language: en-US From: Robin Dapp In-Reply-To: <20230530060621.31449-1-kito.cheng@sifive.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.1 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: Hi Kito, > GNU vector extensions is widly used around this world, and this patch > enable that with RISC-V vector extensions, this can help people > leverage existing code base with RVV, and also can write vector programs in a > familiar way. > > The idea of VLS code gen support is emulate VLS operation by VLA operation with > specific length. > > Key design point is we defer the mode conversion (From VLS to VLA mode) after > register allocation, it come with several advantages: > - VLS pattern is much friendly for most optimization pass like combine. > - Register allocator can spill/restore exact size of VLS type instead of > whole register. > > This is compatible with VLA vectorization. > > Only support move and binary part of operation patterns. On a high-level: Why do we need to do it this way and not any other way? :) Some more comments/explanations would definitely help, i.e. prior art on aarch64, what exactly is easier for combine and friends now (no undef and so on) and, importantly, why is the conversion after register allocation always safe? Couldn't we "lower" the fixed-length vectors to VLA at some point and how does everything relate to fixed-vlmax? Essentially this is a "separate" backend similar to ARM NEON but we share most of the things and possibly grow it in the future? What would the alternative be? That said, couldn't we reuse the existing binop tests? If you don't like them change the existing ones as well and reuse then? > +/* Return the minimal containable VLA mode for MODE. */ > + > +machine_mode > +minimal_vla_mode (machine_mode mode) > +{ > + gcc_assert (GET_MODE_NUNITS (mode).is_constant ()); > + unsigned type_size = GET_MODE_NUNITS (mode).to_constant (); Couldn't you use .require () right away? Same in some other hunks. Regards Robin