From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) by sourceware.org (Postfix) with ESMTPS id B69B43858D33 for ; Wed, 12 Apr 2023 23:18:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B69B43858D33 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-pj1-x102c.google.com with SMTP id pm7-20020a17090b3c4700b00246f00dace2so5382017pjb.2 for ; Wed, 12 Apr 2023 16:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681341491; x=1683933491; 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=43F/tvljQD5LrkDzzmpaba6YuRBMBHOAYLqQC9D8AL4=; b=BikEL/s6dtt9LKU37eB4yEabbtI4wxqzB+9jwvc+r7sA81BY+FhomWdNmDLszSw3F+ 43Qa4xB7qIjlSCzqQkuqHLhmEDpxADzswHmnawgnfV8H7GLL/vaDRCaiH7qV5DHPsywp HpoU0tXq3L7vzMrq+mCujZ+lPeCinJwo+Xf8M0agiT4oswVdzCpd+yJJVqmRcrC3TR1p zmZ0Vs7OFUvIQHChdieXSnTDgwkcmqXX0RbQ1hq3iEK3P7PCrkJvgfW7ktLd3gmgOFrH clUavARy8b860/Wx9LPe4G9KomMbI4OEWnJ/GcohYD578X0OE44IpDFlruwQ7zjmtj3S /wfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681341491; x=1683933491; 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=43F/tvljQD5LrkDzzmpaba6YuRBMBHOAYLqQC9D8AL4=; b=fQJz0cutibwXjyUIoMVMihCS1RftiE/LKhWUznXG1gt94EeSsaVU3FP1Uwc7PQuwWc 5bgNnusPFlHicJOiexuXQOwSJVL9AIDk2MJipPZwwpqDKUhQ1IxEMrC30fzmqEZ1VBJT s1ECMBoyFrfCx+O0nvwT0fimCfWLE1OMpjvb0YAqmCszLZqdzN9XEhcR0Ggdoe0DRHbU l0Yw8NiGmuiHwwu50arwEi3aRPW1AGHw3xQwMb+NmIO87AOCpi40ldJFxhBSdZb8W9s4 LnU5WGwK/s85ceW8M8tUeBMGxUT/aOHvQ1JKDjNj774Nx38Zjw06hW9RY6zHu5YlZYHb WDHw== X-Gm-Message-State: AAQBX9esTCi8mukO7wBrk0Fu6Tz+EkZ1iUOL6P7ZGDNgeUyp/1vT/Vfq +ZqK+PlZQLCsApqUG0xt1uY= X-Google-Smtp-Source: AKy350YflM1XD+ylE6glCbAa6eI+xV6sNjZ2Qj037ZSiJ2qcFv0qT0irhgmxv0Ygnf3UpS6IHzFRTw== X-Received: by 2002:a17:902:fb46:b0:1a1:595a:8e3b with SMTP id lf6-20020a170902fb4600b001a1595a8e3bmr465171plb.34.1681341491363; Wed, 12 Apr 2023 16:18:11 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id w14-20020a170902d70e00b001a04d27ee92sm100349ply.241.2023.04.12.16.18.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Apr 2023 16:18:10 -0700 (PDT) Message-ID: <72a5174a-cf75-8b90-e9e4-bad2b03e665a@gmail.com> Date: Wed, 12 Apr 2023 17:18:09 -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: Fix PR108279 Content-Language: en-US To: juzhe.zhong@rivai.ai, gcc-patches Cc: "kito.cheng" , palmer References: <20230327065907.155807-1-juzhe.zhong@rivai.ai> <7117f9e5-2a82-87d5-66e9-633d9f55cc2d@gmail.com> <127758663DFFBC5C+2023040306404192617341@rivai.ai> <7a8ef74e-6091-2ab9-7831-8fef2f8b8a63@gmail.com> <25FF0653055C8F40+2023040521531356688620@rivai.ai> From: Jeff Law In-Reply-To: <25FF0653055C8F40+2023040521531356688620@rivai.ai> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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,KAM_NUMSUBJECT,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 4/5/23 07:53, juzhe.zhong@rivai.ai wrote: > >> So fusion in this context is really about identifying cases where two >>>configuration settings are equivalent and you "fuse" them together. >>>Presumably this is only going to be possible when the vector insns are >>>just doing data movement rather than actual computations? > >>>If my understanding is correct, I can kind of see why you're doing >>>fusion during phase 3.  My sense is there's a better way, but I'm having >>>a bit of trouble working out the details of what that should be to >>>myself.  In any event, revamping parts of the vsetvl insertion code >>>isn't the kind of thing we should be doing now. > > The vsetvl demand fusion happens is not necessary "equivalent", instead, we > call it we will do demand fusion when they are "compatible". > And the fusion can happen between any vector insns including data movement > and actual computations. I wasn't precise enough in my language, sorry about that. "compatible" would definitely have been a better choice of words on my part. > > What is "compatible" ??  This definition is according to RVV ISA. > For example , For a vadd.vv need a vsetvl zero, 4, e32,m1,ta,ma. > and a vle.v need a vsetvl zero,4,e8,mf4,ta,ma. > > According to RVV ISA: > vadd.vv demand SEW = 32, LMUL = M1, AVL = 4 > vle.v demand RATIO = SEW/LMUL = 32, AVL = 4. > So after demand fusion, the demand becomes SEW = 32, LMUL = M1, AVL = 4. > Such vsetvl instruction is configured as this demand fusion, we call it > "compatible" > since we can find a common vsetvl VL/VTYPE status for both vadd.vv and vle.v Thanks. Yea, that makes sense. Maybe a better way to state what I was thinking was that for pure data movement we have degrees of freedom to adjust the vector configuration to match something else and thus remove a vsetvl. jeff