From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id 6C3953858438 for ; Thu, 29 Jun 2023 09:09:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6C3953858438 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-x629.google.com with SMTP id a640c23a62f3a-98de21518fbso55932066b.0 for ; Thu, 29 Jun 2023 02:09:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688029759; x=1690621759; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ZwCNj4oj/WzS/+rISPaF0agmIjEQMhyGospID8LAwJc=; b=kfbyzIsE0J4mZl9gErE0Voh4qXo1Vw/5MqeOWvUDMhqerodEtQ9YccpqF/iCv72DJ2 O+8i71e4+vPTszEjVunta00dwSxUMkaL9mhEHshV+oUmoob0xfe6zVG2iWDApyiyXgYF 3xhOWWJqe3GiSHm5YfoxtPgztnWGCYRo06ih6qjiZD6B/8Bptw+gd2kZt1n7ZGNv3JOw rBImviwLBsCHlFWMXhUtc2SxG0gpf76h7XbvHCZvjCk9hQOdX7hPj0kKjBgZzBuHOkMa rcu4ZBIzlSjFuX5+NBxQq3peF6BgZdqj5cOJJgb8qTCX9rMtqkAFL2haKHeYjWG+5JFo N9fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688029759; x=1690621759; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZwCNj4oj/WzS/+rISPaF0agmIjEQMhyGospID8LAwJc=; b=YcCm1GaOHeERLkdscOUg6eyB3hbckSWsi6gq06baY5DPa/jwYHQNNrKtYe5uPM8OGP +CUzudAi8E0wzubVBcBMQglJkOrh6xb3sROzLdK7muZd+XlCSYTaY+elTLOQ6S6I2KDd uByXgphLi180I1I0Dismf4tfs2aulgAWJc0p71e2IZMKgmodfArAYx6CowqP3kOtuXgY oNkEbmB7mDZPhd7Ua/jUNTB50j1UVF634HgyOxRUthhej2dKjyWjHgoFbTlh+yS/Q1Cu jwBTN1Xq/jtHL7PnKZmMoZwCHYzum+L63opvpD9IuO8F+J0PuMj8WA4lwwUvR2J/B4bg NnPw== X-Gm-Message-State: AC+VfDzzHDnul8Ftz45Q3UbEI6bRDHADMee43wN7I+hDpBC+b4R41VOb 5sg3ckGo+RZdrPP6wePnZD++s7IEC7c= X-Google-Smtp-Source: ACHHUZ7MRuRk0F2gEwpU45uTn63tTaYGtkhnULNYd3HZ8XaxHjzZh9iRxvuQ5FvicTuqq4dBMp3a/Q== X-Received: by 2002:a17:907:7ba5:b0:973:fd02:a41f with SMTP id ne37-20020a1709077ba500b00973fd02a41fmr37514951ejc.40.1688029758819; Thu, 29 Jun 2023 02:09:18 -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 v20-20020aa7dbd4000000b00514a5f7a145sm5479981edt.37.2023.06.29.02.09.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jun 2023 02:09:18 -0700 (PDT) Message-ID: Date: Thu, 29 Jun 2023 11:09:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Cc: rdapp.gcc@gmail.com Subject: Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI Content-Language: en-US To: Robin Dapp via Gcc-patches , =?UTF-8?B?6ZKf5bGF5ZOy?= , Jeff Law , "kito.cheng" , "kito.cheng" , palmer , palmer , richard.sandiford@arm.com References: <20230628094752.332289-1-juzhe.zhong@rivai.ai> <59DD619A76E2AC1A+2023062903025467496516@rivai.ai> <0f48c2b7-a24d-6223-3805-d755c8eb7a7c@gmail.com> <85bfdc0a-6b55-a72c-b8d8-656b40b0003a@gmail.com> From: Robin Dapp In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_MANYTO,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: > Yeah, that part is OK, and was the case I was thinking about when > I said OK yesterday. But now that we allow BITSIZE != PRECISION, > it's possible for BITSIZE - PRECISION to be more than a full byte, > in which case the new loop would not initialise every byte of > the mode. Ah, I see, so when e.g. BITSIZE == 16 and PRECISION == 1. Luckily this cannot happen with RVV as all we do is adjust the precision of the modes that have BITSIZE == 8. I'm going to add an assert. Juzhe would rather work around that in the backend, though. The other thing I just noticed is tree build_truth_vector_type_for_mode (poly_uint64 nunits, machine_mode mask_mode) { gcc_assert (mask_mode != BLKmode); unsigned HOST_WIDE_INT esize; if (VECTOR_MODE_P (mask_mode)) { poly_uint64 vsize = GET_MODE_BITSIZE (mask_mode); esize = vector_element_size (vsize, nunits); } else esize = 1; tree bool_type = build_nonstandard_boolean_type (esize); return make_vector_type (bool_type, nunits, mask_mode); } which gives us wrong precision as we rely on the BITSIZE here as well. This results in a precision of 1 for VNx8BI, 2 for VNx4BI and 4 for VNx2BI. Maybe this isn't a problem per se but to me it appears just wrong. Regards Robin