From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) by sourceware.org (Postfix) with ESMTPS id 2AD413858D3C for ; Tue, 12 Sep 2023 03:00:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2AD413858D3C 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-pf1-x42e.google.com with SMTP id d2e1a72fcca58-68bed2c786eso4237241b3a.0 for ; Mon, 11 Sep 2023 20:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694487649; x=1695092449; darn=gcc.gnu.org; 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=9Yg3CAImPPMgUg97zEyeRk4xez4qzs2CXto37ilkh08=; b=k00Jm1S4MqN0ngI7/p+XsM/VbCsCfj4n3xIdXpIm7ONCcv0lovax/wSFWmHTQIr156 iD3PO6QCVsoG/D3mNDxCIwhcv3SD6MUEPJge++mLBXEg9ilJp3hrxscCr1avDUcvEQeE q/mLCDCD04oGdQku/ZbTKsIXWcbFEjbScildz51bhRz66fnONUa8RZ2QD83TF0cCyZX3 +A9b+RqRDe3BfQd8/84D9IM3i85x10y3WvxaCbaFEvbG1t4j0F+wL5ZvNEiOaFHOhXA5 0pU2+rgHI80lrP3YW674aqdYLL1E86iUD5epA/8Uth4p3VZ7YP07e7SKiNqb2zB5pyzR FQzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694487649; x=1695092449; 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=9Yg3CAImPPMgUg97zEyeRk4xez4qzs2CXto37ilkh08=; b=KlAMNBjTVY22m0Y6/tOITpQyfUJomJUVp0hNijD24pFD60LUKkK3SIcyJ1h/J5DORH p+AFTKH3iNPkbpiH4u7dPq7ZS5zyTtD1dKsz+Rt+GSiRqG1wsiFo56q9WsAn3RpXJ0p0 lkiwvs2wVsRV3CNiA+tTi4EoBqF42i8dctQscYOWtLjHqPNGYkzM84vZtjiA0G9OgrRO QOYy83GgPBUEuYso2E0ihd1fNUhsRbW8dyPlaZvY/ok1q30gy7e+1dGqokg6+dq9YGou bNOH4kqP8T+c3JT6crPpmAK0P7/nXuM48OEB2X/CnXhRBS184dOKdyMeVoLaAl7FnmvB MWRw== X-Gm-Message-State: AOJu0YxjpeGcgsb8injo7LEZk2yT887QyqI77EfSoVBs8qu5MyuqrJB5 XwtkjF3bGs7U6ZDi8SDrp1Q= X-Google-Smtp-Source: AGHT+IGuCvUqH5slMgo4SE2Z10p2Qt8kDeDQBptuZEPHSkE0YTd3m4YOaAgJ+F9kftJ/TRMcCjgTzA== X-Received: by 2002:a05:6a20:431c:b0:133:86c:e805 with SMTP id h28-20020a056a20431c00b00133086ce805mr12034664pzk.10.1694487648980; Mon, 11 Sep 2023 20:00:48 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id s12-20020a170902ea0c00b001c3bc7b880csm2345257plg.256.2023.09.11.20.00.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Sep 2023 20:00:48 -0700 (PDT) Message-ID: Date: Mon, 11 Sep 2023 21:00:43 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] RISC-V: Finish Typing Un-Typed Instructions and Turn on Assert Content-Language: en-US To: Lehua Ding , Edwin Lu , gcc-patches@gcc.gnu.org Cc: gnu-toolchain@rivosinc.com References: <20230911225308.2275313-1-ewlu@rivosinc.com> <9F63A23D4D863426+7ccedfd0-d4fe-4e8f-b06b-fe08817eabce@rivai.ai> From: Jeff Law In-Reply-To: <9F63A23D4D863426+7ccedfd0-d4fe-4e8f-b06b-fe08817eabce@rivai.ai> 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,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 9/11/23 20:33, Lehua Ding wrote: > Hi Edwin, > > Sorry to bother you. I have a small question for you. > > On 2023/9/12 6:52, Edwin Lu wrote: >> --- a/gcc/config/riscv/autovec-opt.md +++ >> b/gcc/config/riscv/autovec-opt.md @@ -649,7 +649,8 @@ >> (define_insn_and_split "*cond_" gen_int_mode >> (GET_MODE_NUNITS (mode), Pmode)}; >> riscv_vector::expand_cond_len_unop (icode, ops); DONE; -}) +} >> +[(set_attr "type" "vector")]) > > Is it necessary to add type attribute to these INSNs that exist only > before split1 pass? These instructions are expanded into the pattern in > vector.md after split1 pass and do not reach the sched1 pass at all. If > so, I feel that these patterns cannot be added, and it is reasonable to > report an error if these INSNs reach sched1 pass. Thanks. I'd rather be consistent and make it policy that every insn has a type. The next thing I'd like to do (and it's probably much more work) is to validate that every insn type maps to a functional unit for the sched2 pass. The scheduler will do some horrible things to the generated code when lots of insns either don't have types or the types aren't matched to a functional unit. Jeff