From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) by sourceware.org (Postfix) with ESMTPS id 1E0D63858D28 for ; Wed, 12 Apr 2023 09:06:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1E0D63858D28 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-ua1-x929.google.com with SMTP id a38so6767763uax.12 for ; Wed, 12 Apr 2023 02:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681290380; x=1683882380; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=FFfH5T4sYX3ts3jQY1usN9N7VFWtqY0vtS2MsIqXo8w=; b=AWaPybVhL/OSCm0BybxmaZYMnJGfnGAFATQUFmL7+2W/pIpQLVze5+rIAN528YQY0t I0y/yyT1KV4BadypPT/mPpPIt3tPluY1aHLiEXJKY0kHlQYzLdygyS46gi3w1R26+2JZ OnEPm3z2H0XYF2rP8KtV/X6hfQPKiG+fpBQMYs2KamGZUE10bUHtqZaZEK5a0cJ0TbaE dRSdjmsvJC2EMvxwCjGaT5wvH3NzzzUubEw+iWYqiTr+epecNWMg98BzllTRbngzgAC2 93qbFiiOS4rDU1l5X1YPf6nIlJAvYhQoaB7q2MVgkJKA45NrmBNxXNfpnqWQTF87SO1m iofg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681290380; x=1683882380; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FFfH5T4sYX3ts3jQY1usN9N7VFWtqY0vtS2MsIqXo8w=; b=TXyoGp5ltmZakVl12EntWvFCwIspw3DGy9JKNvFNBFTWBb5d8jMsGqgWp0URpMNOHI vZdzN77lWC0jGbRa9jA5mCEQsfzO3/iO0IOPqL3ULUbsFSY0fa/tqWrxuqf7Wzoq16OI Fb95u1XKAzyQjMUuDLhMpATxj/C49JjA5GVAMyWeTbhGpBVtXGE2RsG8OEB/xP2QwzGp mJ9AOhYqYhr/7gqzY943DKSVhfABtEJ+POxmS2Nba7Gmeq1Wke7j+MFbUGeIlc0PodQp KLxgEKMzRMocNDm57Lc5FMxR7EZitpeFCgzPbHpdM7rsuCZ6bwpdj4SrgPyY+gqki3ph vLGg== X-Gm-Message-State: AAQBX9cRh28iJECjZ5R4kz38+0Vo32DO97Q4HEcq+ypggbWnUNloOUQW vRV8uNN706k2aEU3KwyToUOU/qIL6eO0ShHHT/4= X-Google-Smtp-Source: AKy350aAxn4VstHmyBJtDT83pZFIXyLsgHyFR18BuEAj+HfBldJ55RaRFhswaSGRNHqhAfMk7Qiyxk7icLtdCijNJr4= X-Received: by 2002:ab0:1054:0:b0:771:e541:d81b with SMTP id g20-20020ab01054000000b00771e541d81bmr829940uab.0.1681290380152; Wed, 12 Apr 2023 02:06:20 -0700 (PDT) MIME-Version: 1.0 References: <20230410144808.324346-1-juzhe.zhong@rivai.ai> <89f088ec-8692-01f5-0395-5a66ddf085d7@gmail.com> <47D962C7C724E3A2+20230410231445834316202@rivai.ai> <0AEFD2378C3DF89B+202304111919556577872@rivai.ai> In-Reply-To: From: Kito Cheng Date: Wed, 12 Apr 2023 17:06:08 +0800 Message-ID: Subject: Re: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to 16-bit To: Richard Biener Cc: "juzhe.zhong@rivai.ai" , "richard.sandiford" , jeffreyalaw , gcc-patches , palmer , jakub Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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: Hi Richard: > > In order to model LMUL in backend, we have to the combination of > > scalar type and LMUL; possible LMUL is 1, 2, 4, 8, 1/2, 1/4, 1/8 - 8 > > different types of LMUL, and we'll have QI, HI, SI, DI, HF, SF and DF, > > so basically we'll have 7 (LMUL type) * 7 (scalar type) here. > > Other archs have load/store-multiple instructions, IIRC those > are modeled with the appropriate set of operands. Do RVV LMUL > group inputs/outputs overlap with the non-LMUL grouped registers > and can they be used as aliases or is this supposed to be > implemented transparently on the register file level only? LMUL and non-LMUL (or LMUL=1) modes use the same vector register file. Reg for LMUL=1/2 : { {v0, v1, ...v31} } Reg for LMUL=1 : { {v0, v1, ...v31} } Reg for LMUL=2 : { {v0, v1}, {v2, v3}, ... {v30, v31} } // reg. must align to multiple of 2. Reg for LMUL=4 : { {v0, v1, v2, v3}, {v4, v5, v6, v7}, ... {v28, v29, v30, v31} } // reg. must align to multiple of 4. .. Reg for 2-tuples of LMUL=1 : { {v0, v1}, {v1, v2}, ... {v29, v30}, {v30, v31} } Reg for 2-tuples of LMUL=2 : { {v0, v1, v2, v3}, {v2, v3, v4, v5}, ... {v28, v29, v30, v31}, {v28, v29, v30, v31} } // reg. must align to multiple of 2. ... > But yes, implementing this as operations on multi-register > ops with large modes is probably the only sensible approach. > > I don't see how LMUL of 1/2, 1/4 or 1/8 is useful though? Can you > explain? Is that supposed to virtually increase the number of > registers? How do you represent r0:1/8:0 vs r0:1/8:3 (the first > and the third "virtual" register decomposed from r0) in GCC? To > me the natural way would be a subreg of r0? > > Somehow RVV seems to have more knobs than necessary for tuning > the actual vector register layout (aka N axes but only N-1 dimensions > thus the axes are The concept of fractional LMUL is the same as the concept of AArch64's partial SVE vectors, so they can only access the lowest part, like SVE's partial vector. We want to spill/restore the exact size of those modes (1/2, 1/4, 1/8), so adding dedicated modes for those partial vector modes should be unavoidable IMO. And even if we use sub-vector, we still need to define those partial vector types.